hi all,
i want to build all external from the cvs on my linux box (gentoo). i don't know if i'm doing it the right way:
cvs -d:pserver:anonymous@cvs.pure-data.sourceforge.net:/cvsroot/pure-data co externals
cd externals/build/linux/ vi makefile (uncomment Pentium 4, comment default) make
cc -fPIC -DPD -DUNIX -funroll-loops -fomit-frame-pointer -O3
-mfpmath=sse -mmmx -msse -msse2 -march=pentium4 -Wall -W -Wshadow
-Wstrict-prototypes -Wno-unused -Wno-parentheses -Wno-switch -I. -I..
-I../include -o "slider.o" -c "../src/slider.c"
In file included from ../../ggee/gui/slider.c:4,
from ../src/slider.c:1:
../../ggee/gui/fatom.h: In function fatom_new': ../../ggee/gui/fatom.h:422: warning: unsigned int format, pointer arg (arg 3) In file included from ../src/slider.c:1: ../../ggee/gui/slider.c: In functionslider_save':
../../ggee/gui/slider.c:14: error: structure has no member named x_send' ../../ggee/gui/slider.c: In functionslider_new':
../../ggee/gui/slider.c:23: error: incompatible type for argument 3 of
fatom_new' ../../ggee/gui/slider.c:23: error: too few arguments to functionfatom_new'
make: *** [slider.pd_linux] Error 1
patrick
Yeah, I had a problem with slider and hslider too, but I haven't looked
into it. If you want to compile the rest, just:
rm externals/build/src/slider.c rm externals/build/src/hslider.c cd externals/build/linux make clean make
.hc
On Apr 7, 2005, at 9:58 PM, patrick wrote:
hi all,
i want to build all external from the cvs on my linux box (gentoo). i don't know if i'm doing it the right way:
cvs -d:pserver:anonymous@cvs.pure-data.sourceforge.net:/cvsroot/pure-data
co externalscd externals/build/linux/ vi makefile (uncomment Pentium 4, comment default) make
cc -fPIC -DPD -DUNIX -funroll-loops -fomit-frame-pointer -O3 -mfpmath=sse -mmmx -msse -msse2 -march=pentium4 -Wall -W -Wshadow -Wstrict-prototypes -Wno-unused -Wno-parentheses -Wno-switch -I. -I.. -I../include -o "slider.o" -c "../src/slider.c" In file included from ../../ggee/gui/slider.c:4, from ../src/slider.c:1: ../../ggee/gui/fatom.h: In function
fatom_new': ../../ggee/gui/fatom.h:422: warning: unsigned int format, pointer arg (arg 3) In file included from ../src/slider.c:1: ../../ggee/gui/slider.c: In functionslider_save': ../../ggee/gui/slider.c:14: error: structure has no member named
x_send' ../../ggee/gui/slider.c: In functionslider_new': ../../ggee/gui/slider.c:23: error: incompatible type for argument 3 offatom_new' ../../ggee/gui/slider.c:23: error: too few arguments to functionfatom_new' make: *** [slider.pd_linux] Error 1patrick
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
"Computer science is no more related to the computer than astronomy is
related to the telescope."
-Edsger Dykstra
Hi,
You might as well remove these from the build system, as I do not plan to maintain them anymore.
Guenter
On Fri, 8 Apr 2005, Hans-Christoph Steiner wrote:
Yeah, I had a problem with slider and hslider too, but I haven't looked into it. If you want to compile the rest, just:
rm externals/build/src/slider.c rm externals/build/src/hslider.c cd externals/build/linux make clean make
.hc
On Apr 7, 2005, at 9:58 PM, patrick wrote:
hi all,
i want to build all external from the cvs on my linux box (gentoo). i don't know if i'm doing it the right way:
cvs -d:pserver:anonymous@cvs.pure-data.sourceforge.net:/cvsroot/pure-data co externals
cd externals/build/linux/ vi makefile (uncomment Pentium 4, comment default) make
cc -fPIC -DPD -DUNIX -funroll-loops -fomit-frame-pointer -O3 -mfpmath=sse -mmmx -msse -msse2 -march=pentium4 -Wall -W -Wshadow -Wstrict-prototypes -Wno-unused -Wno-parentheses -Wno-switch -I. -I.. -I../include -o "slider.o" -c "../src/slider.c" In file included from ../../ggee/gui/slider.c:4, from ../src/slider.c:1: ../../ggee/gui/fatom.h: In function
fatom_new': ../../ggee/gui/fatom.h:422: warning: unsigned int format, pointer arg (arg 3) In file included from ../src/slider.c:1: ../../ggee/gui/slider.c: In functionslider_save': ../../ggee/gui/slider.c:14: error: structure has no member namedx_send' ../../ggee/gui/slider.c: In functionslider_new': ../../ggee/gui/slider.c:23: error: incompatible type for argument 3 offatom_new' ../../ggee/gui/slider.c:23: error: too few arguments to functionfatom_new' make: *** [slider.pd_linux] Error 1patrick
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
"Computer science is no more related to the computer than astronomy is related to the telescope." -Edsger Dykstra
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Yeah, I had a problem with slider and hslider too, but I haven't looked into it. If you want to compile the rest, just:
rm externals/build/src/slider.c rm externals/build/src/hslider.c cd externals/build/linux make clean make
thanks hans! it works now. but, i was wondering about a thing. why is zexy.pd_linux not in /build/linux? or pmpd? what other externals are not compile/copy?
patrick
On Apr 9, 2005, at 10:35 PM, patrick wrote:
Yeah, I had a problem with slider and hslider too, but I haven't
looked into it. If you want to compile the rest, just:rm externals/build/src/slider.c rm externals/build/src/hslider.c cd externals/build/linux make clean make
thanks hans! it works now. but, i was wondering about a thing. why is zexy.pd_linux not in /build/linux? or pmpd? what other externals are
not compile/copy?
Those have their own build system. No one has added them to the
externals/build setup. Ideally everything would be built there...
.hc
"I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits."
- Martin Luther King, Jr.
hello,
Hans-Christoph Steiner wrote:
...
thanks hans! it works now. but, i was wondering about a thing. why is zexy.pd_linux not in /build/linux? or pmpd? what other externals are not compile/copy?
Those have their own build system. No one has added them to the
externals/build setup. Ideally everything would be built there...
yes, they have there own build system and it's not really a good point. they really should be in the external build system : it is so usefull...
i had a look at the build system, and i don't really understand how does it work. specially to link all .c file to the /src folder. the readme says "In order to be platform independent this is done via c-includes." (?) is there some more documentation somwhere to explain how to add stuff to the build system?
thanks Cyrille
.hc
"I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits."- Martin Luther King, Jr.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Yes, the documentation is lacking. I updated externals/build/README
and externals/build/TODO. Hopefully it'll be more helpful now. Here's
how to add externals that use libs (from README), for example:
Externals That Need Libraries
In order to add an external that needs libraries to this build system,
create
a "libs" file with the exact same name as the source file (i.e.
oggread~.c and
oggread~.libs). If the .libs file has cross-platforms library options,
it
should go into externals/build/src. .libs files for platform-specific
library
options go in externals/build/PLATFORM (see TODO, this isn't totally
implemented).
.hc
On Apr 11, 2005, at 5:56 PM, cyrille wrote:
hello,
Hans-Christoph Steiner wrote:
...
thanks hans! it works now. but, i was wondering about a thing. why is zexy.pd_linux not in /build/linux? or pmpd? what other externals are
not compile/copy?Those have their own build system. No one has added them to the
externals/build setup. Ideally everything would be built there...yes, they have there own build system and it's not really a good point. they really should be in the external build system : it is so
usefull...i had a look at the build system, and i don't really understand how
does it work. specially to link all .c file to the /src folder. the readme says "In order to be platform independent this is done via
c-includes." (?) is there some more documentation somwhere to explain how to add stuff
to the build system?thanks Cyrille
.hc ______________________________________________________________________ __ ____ "I have the audacity to believe that peoples everywhere can have
three meals a day for their bodies, education and culture for their
minds, and dignity, equality and freedom for their spirits."- Martin Luther King, Jr.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli
Those have their own build system. No one has added them to the
externals/build setup. Ideally everything would be built there...
well, i don't think that the external build system as it is at the moment is the best way to build externals:
- it doesn't handle libraries
- it doesn't handle flext externals
- it doesn't handle special compile time flags / configure scripts / whatever
- it's using old pd header files (0.37)
my 2 ¢ ... tim
On Apr 11, 2005, at 6:34 PM, Tim Blechmann wrote:
Those have their own build system. No one has added them to the externals/build setup. Ideally everything would be built there...
well, i don't think that the external build system as it is at the moment is the best way to build externals:
Feel free to improve it :). The bottom line is that it works for most
cases, and with a simple "make" you can compile most of the externals
in CVS.
- it doesn't handle libraries
It does handle libraries, check out externals/build/src/ogg*.c and
externals/build/linux/ogg*.libs.
- it doesn't handle flext externals
- it doesn't handle special compile time flags / configure scripts / whatever
- it's using old pd header files (0.37)
Feel free to update them if that'll make a difference to something that
you are doing, unless Günter objects. This build system that he wrote
is more flexible that you might guess, tho it is unorthodox. But
considering how chaotic Pd development and the Pd CVS are, I think its
a good solution.
.hc
my 2 ¢ ... tim
--
mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tklatest mp3: kMW.mp3 http://mattin.org/mp3.html
latest cd: Goh Lee Kwang & Tim Blechmann: Drone http://www.geocities.com/gohleekwangtimblechmannduo/
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
"Looking at things from a more basic level, you can come up with a more
direct solution... It may sound small in theory, but it in practice, it
can change entire economies."
- Amy Smith
- it doesn't handle libraries
It does handle libraries, check out externals/build/src/ogg*.c and
externals/build/linux/ogg*.libs.
well, i was thinking about libraries as external libraries like cyclone / zexy
- it doesn't handle flext externals
- it doesn't handle special compile time flags / configure scripts / whatever
- it's using old pd header files (0.37)
Feel free to update them if that'll make a difference to something that you are doing, unless Günter objects. This build system that he wrote is more flexible that you might guess, tho it is unorthodox. But considering how chaotic Pd development and the Pd CVS are, I think its a good solution.
i think, a hook for externals / libraries with their own build system would make sense ...
cheers ... tim
- it's using old pd header files (0.37)
huh? you mean theres a m_pd.h in src/ or build/OS? sounds like a bad idea..
Feel free to update them if that'll make a difference to something that you are doing, unless G?nter objects. This build system that he wrote is more flexible that you might guess, tho it is
i guess you might consider it flexible, if the ability to build a library containing multiple objects is not on your list?
unorthodox. But considering how chaotic Pd development and the Pd CVS are, I think its a good solution.
i think, a hook for externals / libraries with their own build system would make sense ...
are there any of these, besides flext?
- it's using old pd header files (0.37)
huh? you mean theres a m_pd.h in src/ or build/OS? sounds like a bad idea..
exactly m_pd.h didn't really change from 0.37 to 0.38, not sure about m_imp.h / g_canvas.h, though ... butthey are private headers and shoudn't be used by externals, althought e.g. flext or cyclone _are_ using them. (so they are de facto public) ...
unorthodox. But considering how chaotic Pd development and the Pd CVS are, I think its a good solution.
i think, a hook for externals / libraries with their own build system would make sense ...
are there any of these, besides flext?
cyclone, toxy, gem, zexy, plugin~ ...
t
Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:
- it's using old pd header files (0.37)
huh? you mean theres a m_pd.h in src/ or build/OS? sounds like a bad idea..
exactly m_pd.h didn't really change from 0.37 to 0.38, not sure about m_imp.h / g_canvas.h, though ... butthey are private headers and shoudn't be used by externals, althought e.g. flext or cyclone _are_ using them. (so they are de facto public) ...
Hm, I always thought, the build system was using "-I../../../../../../pd/src" (or similar ;) to get the headers from the Pd CVS source. I think, they should do so, especially now, that Miller's sources are in CVS, too.
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: "scans" _ http://footils.org/cms/show/41
huh? you mean theres a m_pd.h in src/ or build/OS? sounds like a bad idea..
exactly m_pd.h didn't really change from 0.37 to 0.38, not sure about m_imp.h / g_canvas.h, though ... butthey are private headers and shoudn't be used by externals, althought e.g. flext or cyclone _are_ using them. (so they are de facto public) ...
they (or a part of their contents) should be made public as soon as possible anyway, because how would one program PD gui objects (like Yves') without them?
best greetings, Thomas
m_pd.h didn't really change from 0.37 to 0.38, not sure about m_imp.h / g_canvas.h, though ... butthey are private headers and shoudn't be used by externals, althought e.g. flext or cyclone _are_ using them. (so they are de facto public) ...
they (or a part of their contents) should be made public as soon as possible anyway, because how would one program PD gui objects (like Yves') without them?
not at all ...
... just kidding .... t
On Apr 12, 2005, at 10:24 AM, Thomas Grill wrote:
huh? you mean theres a m_pd.h in src/ or build/OS? sounds like a bad idea..
exactly m_pd.h didn't really change from 0.37 to 0.38, not sure about m_imp.h
/ g_canvas.h, though ... butthey are private headers and shoudn't be
used by externals, althought e.g. flext or cyclone _are_ using them. (so they are de facto public) ...they (or a part of their contents) should be made public as soon as
possible anyway, because how would one program PD gui objects (like
Yves') without them?
Write them with toxy! Check out carmen's extensions/gui/ix nice GUI
objects. No headers or even compilation necessary.
.hc
If you are not part of the solution, you are part of the problem. - Eldridge Cleaver
Write them with toxy! Check out carmen's extensions/gui/ix nice GUI
objects. No headers or even compilation necessary.
great idea ...
but, how does toxy interact with the gui ... maybe by including private headers?
a grep -Ir g_canvas.h * in pd/externals gives: bbogart/entry/entry.c:#include <g_canvas.h> bbogart/popup/popup.c:#include <g_canvas.h> build/include/CVS/Entries:/g_canvas.h/1.4/dummy timestamp from new-entry//D2005.04.12.10.18.32 build/include/m_pd.h:#define t_array struct _array /* g_canvas.h */ ext13/kalashnikov.c:/*#include "g_canvas.h"*/ ext13/sfread.c.~1.1.1.1.~:#include "g_canvas.h" ext13/m_pd.h:#define t_array struct _array /* g_canvas.h */ ext13/pipewrite~.c:#include "g_canvas.h" ext13/sfread.c:#include "g_canvas.h" footils/knob/knob.c:#include "g_canvas.h" ggee/gui/fatom.c:#include "g_canvas.h" ggee/gui/gcanvas.c:#include "g_canvas.h" ggee/gui/toddle.c:#include "g_canvas.h" ggee/gui/slider.c:#include "g_canvas.h" /* for widgetbehaviour */ ggee/gui/envgen.h:#include "g_canvas.h" ggee/gui/ticker.c:#include "g_canvas.h" ggee/gui/button.c:#include <g_canvas.h> ggee/gui/sliderh.c:#include "g_canvas.h" ggee/gui/image.c:#include "g_canvas.h" grill/dyn/config-pd-linux.txt.~1.5.~:# (the normal header file doesn't work as g_canvas.h is not there) grill/dyn/dyn_pd.h:#include "g_canvas.h" grill/dyn/.#config-pd-linux.txt.1.5:# (the normal header file doesn't work as g_canvas.h is not there) grill/dyn/config-pd-darwin.txt:# where are the PD header files? (m_pd.h, m_imp.h, g_canvas.h) grill/dyn/config-pd-linux.txt:# where are the PD header files? (m_pd.h, m_imp.h, g_canvas.h) grill/flext/configure.ac:dnl check for g_canvas.h in pd folder grill/flext/configure.ac:AC_CHECK_FILE("$sysdir/g_canvas.h",,[echo "$sysdir/g_canvas.h not found" && exit 1]) grill/flext/source/flattr_ed.cpp:#include <g_canvas.h> grill/flext/source/flbase.cpp:#include <g_canvas.h> grill/configure.ac:dnl check for g_canvas.h in pd folder grill/configure.ac:AC_CHECK_FILE("$sysdir/g_canvas.h",,[echo "$sysdir/g_canvas.h not found" && exit 1]) grill/dyn_py/config-pd-darwin.txt:# where are the PD header files? (m_pd.h, m_imp.h, g_canvas.h) grill/dynext/src/main.cpp:#include "g_canvas.h" grill/dynext/config-pd-linux.txt.~1.1.~:# (the normal header file doesn't work as g_canvas.h is not there) grill/dynext/config-pd-linux.txt:# (the normal header file doesn't work as g_canvas.h is not there) grill/flext-0.4.7/configure.ac:dnl check for g_canvas.h in pd folder grill/flext-0.4.7/configure.ac:AC_CHECK_FILE("$sysdir/g_canvas.h",,[echo "$sysdir/g_canvas.h not found" && exit 1]) grill/guitest/flgui.h:#include <g_canvas.h> iemlib/src/iemlib2/iem_send_kernel.c:#include "g_canvas.h" iemlib/src/iemlib2/dollarg.c:#include "g_canvas.h" iemlib/src/iemlib2/iem_anything_kernel.c:#include "g_canvas.h" iemlib/src/iemlib2/iem_prepend_kernel.c:#include "g_canvas.h" iemlib/src/iemlib2/iem_receive_kernel.c:#include "g_canvas.h" iemlib/src/iemlib2/iem_append_kernel.c:#include "g_canvas.h" miXed/toxy/plustot.c:#include "g_canvas.h" miXed/toxy/tot.c:#include "g_canvas.h" miXed/toxy/widget.c:#include "g_canvas.h" miXed/toxy/plustot.env.c:#include "g_canvas.h" miXed/cyclone/hammer/pv.c:#include "g_canvas.h" miXed/cyclone/hammer/comment.c:#include "g_canvas.h" miXed/cyclone/hammer/coll.c:#include "g_canvas.h" miXed/cyclone/hammer/Table.c:#include "g_canvas.h" miXed/cyclone/hammer/universal.c:#include "g_canvas.h" miXed/cyclone/sickle/capture.c:#include "g_canvas.h" miXed/cyclone/sickle/Scope.c:#include "g_canvas.h" miXed/shared/toxy/scriptlet.c:#include "g_canvas.h" miXed/shared/unstable/forky.c:#include "g_canvas.h" miXed/shared/unstable/fringe.c:#include "g_canvas.h" miXed/shared/common/port.c:#include "g_canvas.h" miXed/shared/common/vefl.c:#include "g_canvas.h" miXed/shared/hammer/gui.c:#include "g_canvas.h" miXed/shared/hammer/file.c:#include "g_canvas.h" pdogg/oggcast~/oggcast~.c:#include "g_canvas.h" pdogg/oggamp~/oggamp~.c:#include "g_canvas.h" pidip/modules/pdp_compose.c:#include "g_canvas.h" pidip/modules/pdp_colorgrid.c:#include "g_canvas.h" pidip/modules/pdp_cmap.c:#include "g_canvas.h" pidip/modules/pdp_ctrack.c:#include "g_canvas.h" unauthorized/grid/grid.c.~1.6.~:#include "g_canvas.h" unauthorized/grid/grid.c:#include "g_canvas.h" unauthorized/grid/.#grid.c.1.6:#include "g_canvas.h" unauthorized/blinkenlights/blinkenlights.c:#include "g_canvas.h" /* some pd's graphical functions */ unauthorized/cooled~/cooled~.c:#include "g_canvas.h" unauthorized/filterbank~/filterbank~.h:#include "g_canvas.h" unauthorized/pianoroll/pianoroll.c:#include "g_canvas.h" unauthorized/audience~/audience~.c:#include "g_canvas.h" unauthorized/mp3amp~/mp3amp~.c:#include "g_canvas.h" unauthorized/exciter/exciter.c:#include "g_canvas.h" unauthorized/probalizer/probalizer.c:#include "g_canvas.h" unauthorized/sonogram~/sonogram~.c:#include "g_canvas.h" unauthorized/sonogram~/sonogram~-joge.c:#include "g_canvas.h" unauthorized/sonogram~/sonogram~-yves.c:#include "g_canvas.h" unauthorized/scratcher~/scratcher~.c:#include "g_canvas.h" unauthorized/speex~/speexin~.c:#include <g_canvas.h> unauthorized/playlist/playlist.c:#include "g_canvas.h" unauthorized/mp3live~/mp3fileout~.c:#include <g_canvas.h> unauthorized/mp3live~/mp3streamin~.c:#include <g_canvas.h>
cheers ... tim
hello, I came back to my original question,
the build system worked great, and it is very usefull. now that i understand the way it works, i commmited a line3.c and pmpd.c in build/src/ that are working as expected.
so, you should now be able to compile pmpd with the rest of the externals...
cyrille
Tim Blechmann a écrit :
Write them with toxy! Check out carmen's extensions/gui/ix nice GUI
objects. No headers or even compilation necessary.great idea ...
but, how does toxy interact with the gui ... maybe by including private headers?
a grep -Ir g_canvas.h * in pd/externals gives: bbogart/entry/entry.c:#include <g_canvas.h> bbogart/popup/popup.c:#include <g_canvas.h> build/include/CVS/Entries:/g_canvas.h/1.4/dummy timestamp from new-entry//D2005.04.12.10.18.32 build/include/m_pd.h:#define t_array struct _array /* g_canvas.h */ ext13/kalashnikov.c:/*#include "g_canvas.h"*/ ext13/sfread.c.~1.1.1.1.~:#include "g_canvas.h" ext13/m_pd.h:#define t_array struct _array /* g_canvas.h */ ext13/pipewrite~.c:#include "g_canvas.h" ext13/sfread.c:#include "g_canvas.h" footils/knob/knob.c:#include "g_canvas.h" ggee/gui/fatom.c:#include "g_canvas.h" ggee/gui/gcanvas.c:#include "g_canvas.h" ggee/gui/toddle.c:#include "g_canvas.h" ggee/gui/slider.c:#include "g_canvas.h" /* for widgetbehaviour */ ggee/gui/envgen.h:#include "g_canvas.h" ggee/gui/ticker.c:#include "g_canvas.h" ggee/gui/button.c:#include <g_canvas.h> ggee/gui/sliderh.c:#include "g_canvas.h" ggee/gui/image.c:#include "g_canvas.h" grill/dyn/config-pd-linux.txt.~1.5.~:# (the normal header file doesn't work as g_canvas.h is not there) grill/dyn/dyn_pd.h:#include "g_canvas.h" grill/dyn/.#config-pd-linux.txt.1.5:# (the normal header file doesn't work as g_canvas.h is not there) grill/dyn/config-pd-darwin.txt:# where are the PD header files? (m_pd.h, m_imp.h, g_canvas.h) grill/dyn/config-pd-linux.txt:# where are the PD header files? (m_pd.h, m_imp.h, g_canvas.h) grill/flext/configure.ac:dnl check for g_canvas.h in pd folder grill/flext/configure.ac:AC_CHECK_FILE("$sysdir/g_canvas.h",,[echo "$sysdir/g_canvas.h not found" && exit 1]) grill/flext/source/flattr_ed.cpp:#include <g_canvas.h> grill/flext/source/flbase.cpp:#include <g_canvas.h> grill/configure.ac:dnl check for g_canvas.h in pd folder grill/configure.ac:AC_CHECK_FILE("$sysdir/g_canvas.h",,[echo "$sysdir/g_canvas.h not found" && exit 1]) grill/dyn_py/config-pd-darwin.txt:# where are the PD header files? (m_pd.h, m_imp.h, g_canvas.h) grill/dynext/src/main.cpp:#include "g_canvas.h" grill/dynext/config-pd-linux.txt.~1.1.~:# (the normal header file doesn't work as g_canvas.h is not there) grill/dynext/config-pd-linux.txt:# (the normal header file doesn't work as g_canvas.h is not there) grill/flext-0.4.7/configure.ac:dnl check for g_canvas.h in pd folder grill/flext-0.4.7/configure.ac:AC_CHECK_FILE("$sysdir/g_canvas.h",,[echo "$sysdir/g_canvas.h not found" && exit 1]) grill/guitest/flgui.h:#include <g_canvas.h> iemlib/src/iemlib2/iem_send_kernel.c:#include "g_canvas.h" iemlib/src/iemlib2/dollarg.c:#include "g_canvas.h" iemlib/src/iemlib2/iem_anything_kernel.c:#include "g_canvas.h" iemlib/src/iemlib2/iem_prepend_kernel.c:#include "g_canvas.h" iemlib/src/iemlib2/iem_receive_kernel.c:#include "g_canvas.h" iemlib/src/iemlib2/iem_append_kernel.c:#include "g_canvas.h" miXed/toxy/plustot.c:#include "g_canvas.h" miXed/toxy/tot.c:#include "g_canvas.h" miXed/toxy/widget.c:#include "g_canvas.h" miXed/toxy/plustot.env.c:#include "g_canvas.h" miXed/cyclone/hammer/pv.c:#include "g_canvas.h" miXed/cyclone/hammer/comment.c:#include "g_canvas.h" miXed/cyclone/hammer/coll.c:#include "g_canvas.h" miXed/cyclone/hammer/Table.c:#include "g_canvas.h" miXed/cyclone/hammer/universal.c:#include "g_canvas.h" miXed/cyclone/sickle/capture.c:#include "g_canvas.h" miXed/cyclone/sickle/Scope.c:#include "g_canvas.h" miXed/shared/toxy/scriptlet.c:#include "g_canvas.h" miXed/shared/unstable/forky.c:#include "g_canvas.h" miXed/shared/unstable/fringe.c:#include "g_canvas.h" miXed/shared/common/port.c:#include "g_canvas.h" miXed/shared/common/vefl.c:#include "g_canvas.h" miXed/shared/hammer/gui.c:#include "g_canvas.h" miXed/shared/hammer/file.c:#include "g_canvas.h" pdogg/oggcast~/oggcast~.c:#include "g_canvas.h" pdogg/oggamp~/oggamp~.c:#include "g_canvas.h" pidip/modules/pdp_compose.c:#include "g_canvas.h" pidip/modules/pdp_colorgrid.c:#include "g_canvas.h" pidip/modules/pdp_cmap.c:#include "g_canvas.h" pidip/modules/pdp_ctrack.c:#include "g_canvas.h" unauthorized/grid/grid.c.~1.6.~:#include "g_canvas.h" unauthorized/grid/grid.c:#include "g_canvas.h" unauthorized/grid/.#grid.c.1.6:#include "g_canvas.h" unauthorized/blinkenlights/blinkenlights.c:#include "g_canvas.h" /* some pd's graphical functions */ unauthorized/cooled~/cooled~.c:#include "g_canvas.h" unauthorized/filterbank~/filterbank~.h:#include "g_canvas.h" unauthorized/pianoroll/pianoroll.c:#include "g_canvas.h" unauthorized/audience~/audience~.c:#include "g_canvas.h" unauthorized/mp3amp~/mp3amp~.c:#include "g_canvas.h" unauthorized/exciter/exciter.c:#include "g_canvas.h" unauthorized/probalizer/probalizer.c:#include "g_canvas.h" unauthorized/sonogram~/sonogram~.c:#include "g_canvas.h" unauthorized/sonogram~/sonogram~-joge.c:#include "g_canvas.h" unauthorized/sonogram~/sonogram~-yves.c:#include "g_canvas.h" unauthorized/scratcher~/scratcher~.c:#include "g_canvas.h" unauthorized/speex~/speexin~.c:#include <g_canvas.h> unauthorized/playlist/playlist.c:#include "g_canvas.h" unauthorized/mp3live~/mp3fileout~.c:#include <g_canvas.h> unauthorized/mp3live~/mp3streamin~.c:#include <g_canvas.h>
cheers ... tim
Excellent! I just compiled it on Darwin/MacOS X and it works fine.
The help files need to be added to, I wrote a little blurb in
externals/build/README about it, but externals/build/doc/makefile
should be self-explanatory.
Now if we could convince you to build pmpd as individual objects...
.hc
On Apr 12, 2005, at 8:37 PM, cyrille wrote:
hello, I came back to my original question,
the build system worked great, and it is very usefull. now that i understand the way it works, i commmited a line3.c and
pmpd.c in build/src/ that are working as expected.so, you should now be able to compile pmpd with the rest of the
externals...cyrille
Tim Blechmann a écrit :
Write them with toxy! Check out carmen's extensions/gui/ix nice GUI
objects. No headers or even compilation necessary.great idea ... but, how does toxy interact with the gui ... maybe by including
private headers? a grep -Ir g_canvas.h * in pd/externals gives: bbogart/entry/entry.c:#include <g_canvas.h> bbogart/popup/popup.c:#include <g_canvas.h> build/include/CVS/Entries:/g_canvas.h/1.4/dummy timestamp from
new-entry//D2005.04.12.10.18.32 build/include/m_pd.h:#define t_array struct _array /*
g_canvas.h */ ext13/kalashnikov.c:/*#include "g_canvas.h"*/ ext13/sfread.c.~1.1.1.1.~:#include "g_canvas.h" ext13/m_pd.h:#define t_array struct _array /* g_canvas.h */ ext13/pipewrite~.c:#include "g_canvas.h" ext13/sfread.c:#include "g_canvas.h" footils/knob/knob.c:#include "g_canvas.h" ggee/gui/fatom.c:#include "g_canvas.h" ggee/gui/gcanvas.c:#include "g_canvas.h" ggee/gui/toddle.c:#include "g_canvas.h" ggee/gui/slider.c:#include "g_canvas.h" /* for widgetbehaviour */ ggee/gui/envgen.h:#include "g_canvas.h" ggee/gui/ticker.c:#include "g_canvas.h" ggee/gui/button.c:#include <g_canvas.h> ggee/gui/sliderh.c:#include "g_canvas.h" ggee/gui/image.c:#include "g_canvas.h" grill/dyn/config-pd-linux.txt.~1.5.~:# (the normal header file
doesn't work as g_canvas.h is not there) grill/dyn/dyn_pd.h:#include "g_canvas.h" grill/dyn/.#config-pd-linux.txt.1.5:# (the normal header file doesn't
work as g_canvas.h is not there) grill/dyn/config-pd-darwin.txt:# where are the PD header files?
(m_pd.h, m_imp.h, g_canvas.h) grill/dyn/config-pd-linux.txt:# where are the PD header files?
(m_pd.h, m_imp.h, g_canvas.h) grill/flext/configure.ac:dnl check for g_canvas.h in pd folder grill/flext/configure.ac:AC_CHECK_FILE("$sysdir/g_canvas.h",,[echo
"$sysdir/g_canvas.h not found" && exit 1]) grill/flext/source/flattr_ed.cpp:#include <g_canvas.h> grill/flext/source/flbase.cpp:#include <g_canvas.h> grill/configure.ac:dnl check for g_canvas.h in pd folder grill/configure.ac:AC_CHECK_FILE("$sysdir/g_canvas.h",,[echo
"$sysdir/g_canvas.h not found" && exit 1]) grill/dyn_py/config-pd-darwin.txt:# where are the PD header files?
(m_pd.h, m_imp.h, g_canvas.h) grill/dynext/src/main.cpp:#include "g_canvas.h" grill/dynext/config-pd-linux.txt.~1.1.~:# (the normal header file
doesn't work as g_canvas.h is not there) grill/dynext/config-pd-linux.txt:# (the normal header file doesn't
work as g_canvas.h is not there) grill/flext-0.4.7/configure.ac:dnl check for g_canvas.h in pd folder grill/flext-0.4.7/configure.ac:AC_CHECK_FILE("$sysdir/ g_canvas.h",,[echo "$sysdir/g_canvas.h not found" && exit 1]) grill/guitest/flgui.h:#include <g_canvas.h> iemlib/src/iemlib2/iem_send_kernel.c:#include "g_canvas.h" iemlib/src/iemlib2/dollarg.c:#include "g_canvas.h" iemlib/src/iemlib2/iem_anything_kernel.c:#include "g_canvas.h" iemlib/src/iemlib2/iem_prepend_kernel.c:#include "g_canvas.h" iemlib/src/iemlib2/iem_receive_kernel.c:#include "g_canvas.h" iemlib/src/iemlib2/iem_append_kernel.c:#include "g_canvas.h" miXed/toxy/plustot.c:#include "g_canvas.h" miXed/toxy/tot.c:#include "g_canvas.h" miXed/toxy/widget.c:#include "g_canvas.h" miXed/toxy/plustot.env.c:#include "g_canvas.h" miXed/cyclone/hammer/pv.c:#include "g_canvas.h" miXed/cyclone/hammer/comment.c:#include "g_canvas.h" miXed/cyclone/hammer/coll.c:#include "g_canvas.h" miXed/cyclone/hammer/Table.c:#include "g_canvas.h" miXed/cyclone/hammer/universal.c:#include "g_canvas.h" miXed/cyclone/sickle/capture.c:#include "g_canvas.h" miXed/cyclone/sickle/Scope.c:#include "g_canvas.h" miXed/shared/toxy/scriptlet.c:#include "g_canvas.h" miXed/shared/unstable/forky.c:#include "g_canvas.h" miXed/shared/unstable/fringe.c:#include "g_canvas.h" miXed/shared/common/port.c:#include "g_canvas.h" miXed/shared/common/vefl.c:#include "g_canvas.h" miXed/shared/hammer/gui.c:#include "g_canvas.h" miXed/shared/hammer/file.c:#include "g_canvas.h" pdogg/oggcast~/oggcast~.c:#include "g_canvas.h" pdogg/oggamp~/oggamp~.c:#include "g_canvas.h" pidip/modules/pdp_compose.c:#include "g_canvas.h" pidip/modules/pdp_colorgrid.c:#include "g_canvas.h" pidip/modules/pdp_cmap.c:#include "g_canvas.h" pidip/modules/pdp_ctrack.c:#include "g_canvas.h" unauthorized/grid/grid.c.~1.6.~:#include "g_canvas.h" unauthorized/grid/grid.c:#include "g_canvas.h" unauthorized/grid/.#grid.c.1.6:#include "g_canvas.h" unauthorized/blinkenlights/blinkenlights.c:#include "g_canvas.h"
/* some pd's graphical functions */ unauthorized/cooled~/cooled~.c:#include "g_canvas.h" unauthorized/filterbank~/filterbank~.h:#include "g_canvas.h" unauthorized/pianoroll/pianoroll.c:#include "g_canvas.h" unauthorized/audience~/audience~.c:#include "g_canvas.h" unauthorized/mp3amp~/mp3amp~.c:#include "g_canvas.h" unauthorized/exciter/exciter.c:#include "g_canvas.h" unauthorized/probalizer/probalizer.c:#include "g_canvas.h" unauthorized/sonogram~/sonogram~.c:#include "g_canvas.h" unauthorized/sonogram~/sonogram~-joge.c:#include "g_canvas.h" unauthorized/sonogram~/sonogram~-yves.c:#include "g_canvas.h" unauthorized/scratcher~/scratcher~.c:#include "g_canvas.h" unauthorized/speex~/speexin~.c:#include <g_canvas.h> unauthorized/playlist/playlist.c:#include "g_canvas.h" unauthorized/mp3live~/mp3fileout~.c:#include <g_canvas.h> unauthorized/mp3live~/mp3streamin~.c:#include <g_canvas.h> cheers ... tim
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
http://at.or.at/hans/
Hans-Christoph Steiner a écrit :
Excellent! I just compiled it on Darwin/MacOS X and it works fine.
thanks, i did not have time to test it on other computer than mine. i'm really happy you spend time to test it for me. what a nice collaboration on the pure data open source community.
The help files need to be added to, I wrote a little blurb in
externals/build/README about it, but externals/build/doc/makefile
should be self-explanatory.
ok, i'll look at it (soon(?)).
Now if we could convince you to build pmpd as individual objects...
hum, like gunter say :
Therefore I think it would be better to have single externals in all cases where there is no shared code.
I aggree with him.
i think pmpd has a unity, like gem or pdp, and that spliting it in differents files is not very good. (unlike libs of trully eparate objects)
if a nameclash occure with pmpd, then it would be better not to load pmpd (using mass without link is non-sens)
in fact, the interactor equations are in the mass objects, so spliting pmpd as individual objects would generate lot's of problems. So i don't think it's a good idea to split pmpd (at least not yet)
anyway, i think the build system is really important for pd in lot's of points. So i'll split pmpd if this could help the build system. (but pmpd is build like a single object, so it's very easy to include it in the build system as it is now)
oh, i also have to say that the new physical modeling object (made by nicolas) are not add to pmpd, but build as separate objects, because they really are single objects. (you can now do physical modeling without pmpd) hum. they use flext because i think open source is sharing idea, informations, or code to the most peoples possible, and that i'm happy to share this object to the max community.
thanks,
cyrille.
.hc
On Apr 12, 2005, at 8:37 PM, cyrille wrote:
hello, I came back to my original question,
the build system worked great, and it is very usefull. now that i understand the way it works, i commmited a line3.c and
pmpd.c in build/src/ that are working as expected.so, you should now be able to compile pmpd with the rest of the
externals...cyrille
Tim Blechmann a écrit :
Write them with toxy! Check out carmen's extensions/gui/ix nice GUI objects. No headers or even compilation necessary.
great idea ... but, how does toxy interact with the gui ... maybe by including
private headers? a grep -Ir g_canvas.h * in pd/externals gives: bbogart/entry/entry.c:#include <g_canvas.h> bbogart/popup/popup.c:#include <g_canvas.h> build/include/CVS/Entries:/g_canvas.h/1.4/dummy timestamp from
new-entry//D2005.04.12.10.18.32 build/include/m_pd.h:#define t_array struct _array /*
g_canvas.h */ ext13/kalashnikov.c:/*#include "g_canvas.h"*/ ext13/sfread.c.~1.1.1.1.~:#include "g_canvas.h" ext13/m_pd.h:#define t_array struct _array /* g_canvas.h */ ext13/pipewrite~.c:#include "g_canvas.h" ext13/sfread.c:#include "g_canvas.h" footils/knob/knob.c:#include "g_canvas.h" ggee/gui/fatom.c:#include "g_canvas.h" ggee/gui/gcanvas.c:#include "g_canvas.h" ggee/gui/toddle.c:#include "g_canvas.h" ggee/gui/slider.c:#include "g_canvas.h" /* for widgetbehaviour */ ggee/gui/envgen.h:#include "g_canvas.h" ggee/gui/ticker.c:#include "g_canvas.h" ggee/gui/button.c:#include <g_canvas.h> ggee/gui/sliderh.c:#include "g_canvas.h" ggee/gui/image.c:#include "g_canvas.h" grill/dyn/config-pd-linux.txt.~1.5.~:# (the normal header file
doesn't work as g_canvas.h is not there) grill/dyn/dyn_pd.h:#include "g_canvas.h" grill/dyn/.#config-pd-linux.txt.1.5:# (the normal header file doesn't work as g_canvas.h is not there) grill/dyn/config-pd-darwin.txt:# where are the PD header files?
(m_pd.h, m_imp.h, g_canvas.h) grill/dyn/config-pd-linux.txt:# where are the PD header files?
(m_pd.h, m_imp.h, g_canvas.h) grill/flext/configure.ac:dnl check for g_canvas.h in pd folder grill/flext/configure.ac:AC_CHECK_FILE("$sysdir/g_canvas.h",,[echo
"$sysdir/g_canvas.h not found" && exit 1]) grill/flext/source/flattr_ed.cpp:#include <g_canvas.h> grill/flext/source/flbase.cpp:#include <g_canvas.h> grill/configure.ac:dnl check for g_canvas.h in pd folder grill/configure.ac:AC_CHECK_FILE("$sysdir/g_canvas.h",,[echo
"$sysdir/g_canvas.h not found" && exit 1]) grill/dyn_py/config-pd-darwin.txt:# where are the PD header files?
(m_pd.h, m_imp.h, g_canvas.h) grill/dynext/src/main.cpp:#include "g_canvas.h" grill/dynext/config-pd-linux.txt.~1.1.~:# (the normal header file
doesn't work as g_canvas.h is not there) grill/dynext/config-pd-linux.txt:# (the normal header file doesn't
work as g_canvas.h is not there) grill/flext-0.4.7/configure.ac:dnl check for g_canvas.h in pd folder grill/flext-0.4.7/configure.ac:AC_CHECK_FILE("$sysdir/ g_canvas.h",,[echo "$sysdir/g_canvas.h not found" && exit 1]) grill/guitest/flgui.h:#include <g_canvas.h> iemlib/src/iemlib2/iem_send_kernel.c:#include "g_canvas.h" iemlib/src/iemlib2/dollarg.c:#include "g_canvas.h" iemlib/src/iemlib2/iem_anything_kernel.c:#include "g_canvas.h" iemlib/src/iemlib2/iem_prepend_kernel.c:#include "g_canvas.h" iemlib/src/iemlib2/iem_receive_kernel.c:#include "g_canvas.h" iemlib/src/iemlib2/iem_append_kernel.c:#include "g_canvas.h" miXed/toxy/plustot.c:#include "g_canvas.h" miXed/toxy/tot.c:#include "g_canvas.h" miXed/toxy/widget.c:#include "g_canvas.h" miXed/toxy/plustot.env.c:#include "g_canvas.h" miXed/cyclone/hammer/pv.c:#include "g_canvas.h" miXed/cyclone/hammer/comment.c:#include "g_canvas.h" miXed/cyclone/hammer/coll.c:#include "g_canvas.h" miXed/cyclone/hammer/Table.c:#include "g_canvas.h" miXed/cyclone/hammer/universal.c:#include "g_canvas.h" miXed/cyclone/sickle/capture.c:#include "g_canvas.h" miXed/cyclone/sickle/Scope.c:#include "g_canvas.h" miXed/shared/toxy/scriptlet.c:#include "g_canvas.h" miXed/shared/unstable/forky.c:#include "g_canvas.h" miXed/shared/unstable/fringe.c:#include "g_canvas.h" miXed/shared/common/port.c:#include "g_canvas.h" miXed/shared/common/vefl.c:#include "g_canvas.h" miXed/shared/hammer/gui.c:#include "g_canvas.h" miXed/shared/hammer/file.c:#include "g_canvas.h" pdogg/oggcast~/oggcast~.c:#include "g_canvas.h" pdogg/oggamp~/oggamp~.c:#include "g_canvas.h" pidip/modules/pdp_compose.c:#include "g_canvas.h" pidip/modules/pdp_colorgrid.c:#include "g_canvas.h" pidip/modules/pdp_cmap.c:#include "g_canvas.h" pidip/modules/pdp_ctrack.c:#include "g_canvas.h" unauthorized/grid/grid.c.~1.6.~:#include "g_canvas.h" unauthorized/grid/grid.c:#include "g_canvas.h" unauthorized/grid/.#grid.c.1.6:#include "g_canvas.h" unauthorized/blinkenlights/blinkenlights.c:#include "g_canvas.h" /* some pd's graphical functions */ unauthorized/cooled~/cooled~.c:#include "g_canvas.h" unauthorized/filterbank~/filterbank~.h:#include "g_canvas.h" unauthorized/pianoroll/pianoroll.c:#include "g_canvas.h" unauthorized/audience~/audience~.c:#include "g_canvas.h" unauthorized/mp3amp~/mp3amp~.c:#include "g_canvas.h" unauthorized/exciter/exciter.c:#include "g_canvas.h" unauthorized/probalizer/probalizer.c:#include "g_canvas.h" unauthorized/sonogram~/sonogram~.c:#include "g_canvas.h" unauthorized/sonogram~/sonogram~-joge.c:#include "g_canvas.h" unauthorized/sonogram~/sonogram~-yves.c:#include "g_canvas.h" unauthorized/scratcher~/scratcher~.c:#include "g_canvas.h" unauthorized/speex~/speexin~.c:#include <g_canvas.h> unauthorized/playlist/playlist.c:#include "g_canvas.h" unauthorized/mp3live~/mp3fileout~.c:#include <g_canvas.h> unauthorized/mp3live~/mp3streamin~.c:#include <g_canvas.h> cheers ... tim
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
http://at.or.at/hans/
Please, do somebody already try to compile it on Debian/powerpc ?
fv
cyrille a écrit :
Hans-Christoph Steiner a écrit :
Excellent! I just compiled it on Darwin/MacOS X and it works fine.
thanks, i did not have time to test it on other computer than mine. i'm really happy you spend time to test it for me. what a nice collaboration on the pure data open source community.
The help files need to be added to, I wrote a little blurb in
externals/build/README about it, but externals/build/doc/makefile
should be self-explanatory.ok, i'll look at it (soon(?)).
Now if we could convince you to build pmpd as individual objects...
hum, like gunter say :
Therefore I think it would be better to have single externals in all cases where there is no shared code.
I aggree with him.
i think pmpd has a unity, like gem or pdp, and that spliting it in differents files is not very good. (unlike libs of trully eparate objects)
if a nameclash occure with pmpd, then it would be better not to load pmpd (using mass without link is non-sens)
in fact, the interactor equations are in the mass objects, so spliting pmpd as individual objects would generate lot's of problems. So i don't think it's a good idea to split pmpd (at least not yet)
anyway, i think the build system is really important for pd in lot's of points. So i'll split pmpd if this could help the build system. (but pmpd is build like a single object, so it's very easy to include it in the build system as it is now)
oh, i also have to say that the new physical modeling object (made by nicolas) are not add to pmpd, but build as separate objects, because they really are single objects. (you can now do physical modeling without pmpd) hum. they use flext because i think open source is sharing idea, informations, or code to the most peoples possible, and that i'm happy to share this object to the max community.
thanks,
cyrille.
.hc
On Apr 12, 2005, at 8:37 PM, cyrille wrote:
hello, I came back to my original question,
the build system worked great, and it is very usefull. now that i understand the way it works, i commmited a line3.c and
pmpd.c in build/src/ that are working as expected.so, you should now be able to compile pmpd with the rest of the
externals...cyrille
Tim Blechmann a écrit :
Write them with toxy! Check out carmen's extensions/gui/ix nice GUI objects. No headers or even compilation necessary.
great idea ... but, how does toxy interact with the gui ... maybe by including
private headers? a grep -Ir g_canvas.h * in pd/externals gives: bbogart/entry/entry.c:#include <g_canvas.h> bbogart/popup/popup.c:#include <g_canvas.h> build/include/CVS/Entries:/g_canvas.h/1.4/dummy timestamp from
new-entry//D2005.04.12.10.18.32 build/include/m_pd.h:#define t_array struct _array /*
g_canvas.h */ ext13/kalashnikov.c:/*#include "g_canvas.h"*/ ext13/sfread.c.~1.1.1.1.~:#include "g_canvas.h" ext13/m_pd.h:#define t_array struct _array /* g_canvas.h */ ext13/pipewrite~.c:#include "g_canvas.h" ext13/sfread.c:#include "g_canvas.h" footils/knob/knob.c:#include "g_canvas.h" ggee/gui/fatom.c:#include "g_canvas.h" ggee/gui/gcanvas.c:#include "g_canvas.h" ggee/gui/toddle.c:#include "g_canvas.h" ggee/gui/slider.c:#include "g_canvas.h" /* for widgetbehaviour */ ggee/gui/envgen.h:#include "g_canvas.h" ggee/gui/ticker.c:#include "g_canvas.h" ggee/gui/button.c:#include <g_canvas.h> ggee/gui/sliderh.c:#include "g_canvas.h" ggee/gui/image.c:#include "g_canvas.h" grill/dyn/config-pd-linux.txt.~1.5.~:# (the normal header file
doesn't work as g_canvas.h is not there) grill/dyn/dyn_pd.h:#include "g_canvas.h" grill/dyn/.#config-pd-linux.txt.1.5:# (the normal header file doesn't work as g_canvas.h is not there) grill/dyn/config-pd-darwin.txt:# where are the PD header files?
(m_pd.h, m_imp.h, g_canvas.h) grill/dyn/config-pd-linux.txt:# where are the PD header files?
(m_pd.h, m_imp.h, g_canvas.h) grill/flext/configure.ac:dnl check for g_canvas.h in pd folder grill/flext/configure.ac:AC_CHECK_FILE("$sysdir/g_canvas.h",,[echo
"$sysdir/g_canvas.h not found" && exit 1]) grill/flext/source/flattr_ed.cpp:#include <g_canvas.h> grill/flext/source/flbase.cpp:#include <g_canvas.h> grill/configure.ac:dnl check for g_canvas.h in pd folder grill/configure.ac:AC_CHECK_FILE("$sysdir/g_canvas.h",,[echo
"$sysdir/g_canvas.h not found" && exit 1]) grill/dyn_py/config-pd-darwin.txt:# where are the PD header files?
(m_pd.h, m_imp.h, g_canvas.h) grill/dynext/src/main.cpp:#include "g_canvas.h" grill/dynext/config-pd-linux.txt.~1.1.~:# (the normal header file
doesn't work as g_canvas.h is not there) grill/dynext/config-pd-linux.txt:# (the normal header file doesn't
work as g_canvas.h is not there) grill/flext-0.4.7/configure.ac:dnl check for g_canvas.h in pd folder grill/flext-0.4.7/configure.ac:AC_CHECK_FILE("$sysdir/ g_canvas.h",,[echo "$sysdir/g_canvas.h not found" && exit 1]) grill/guitest/flgui.h:#include <g_canvas.h> iemlib/src/iemlib2/iem_send_kernel.c:#include "g_canvas.h" iemlib/src/iemlib2/dollarg.c:#include "g_canvas.h" iemlib/src/iemlib2/iem_anything_kernel.c:#include "g_canvas.h" iemlib/src/iemlib2/iem_prepend_kernel.c:#include "g_canvas.h" iemlib/src/iemlib2/iem_receive_kernel.c:#include "g_canvas.h" iemlib/src/iemlib2/iem_append_kernel.c:#include "g_canvas.h" miXed/toxy/plustot.c:#include "g_canvas.h" miXed/toxy/tot.c:#include "g_canvas.h" miXed/toxy/widget.c:#include "g_canvas.h" miXed/toxy/plustot.env.c:#include "g_canvas.h" miXed/cyclone/hammer/pv.c:#include "g_canvas.h" miXed/cyclone/hammer/comment.c:#include "g_canvas.h" miXed/cyclone/hammer/coll.c:#include "g_canvas.h" miXed/cyclone/hammer/Table.c:#include "g_canvas.h" miXed/cyclone/hammer/universal.c:#include "g_canvas.h" miXed/cyclone/sickle/capture.c:#include "g_canvas.h" miXed/cyclone/sickle/Scope.c:#include "g_canvas.h" miXed/shared/toxy/scriptlet.c:#include "g_canvas.h" miXed/shared/unstable/forky.c:#include "g_canvas.h" miXed/shared/unstable/fringe.c:#include "g_canvas.h" miXed/shared/common/port.c:#include "g_canvas.h" miXed/shared/common/vefl.c:#include "g_canvas.h" miXed/shared/hammer/gui.c:#include "g_canvas.h" miXed/shared/hammer/file.c:#include "g_canvas.h" pdogg/oggcast~/oggcast~.c:#include "g_canvas.h" pdogg/oggamp~/oggamp~.c:#include "g_canvas.h" pidip/modules/pdp_compose.c:#include "g_canvas.h" pidip/modules/pdp_colorgrid.c:#include "g_canvas.h" pidip/modules/pdp_cmap.c:#include "g_canvas.h" pidip/modules/pdp_ctrack.c:#include "g_canvas.h" unauthorized/grid/grid.c.~1.6.~:#include "g_canvas.h" unauthorized/grid/grid.c:#include "g_canvas.h" unauthorized/grid/.#grid.c.1.6:#include "g_canvas.h" unauthorized/blinkenlights/blinkenlights.c:#include "g_canvas.h" /* some pd's graphical functions */ unauthorized/cooled~/cooled~.c:#include "g_canvas.h" unauthorized/filterbank~/filterbank~.h:#include "g_canvas.h" unauthorized/pianoroll/pianoroll.c:#include "g_canvas.h" unauthorized/audience~/audience~.c:#include "g_canvas.h" unauthorized/mp3amp~/mp3amp~.c:#include "g_canvas.h" unauthorized/exciter/exciter.c:#include "g_canvas.h" unauthorized/probalizer/probalizer.c:#include "g_canvas.h" unauthorized/sonogram~/sonogram~.c:#include "g_canvas.h" unauthorized/sonogram~/sonogram~-joge.c:#include "g_canvas.h" unauthorized/sonogram~/sonogram~-yves.c:#include "g_canvas.h" unauthorized/scratcher~/scratcher~.c:#include "g_canvas.h" unauthorized/speex~/speexin~.c:#include <g_canvas.h> unauthorized/playlist/playlist.c:#include "g_canvas.h" unauthorized/mp3live~/mp3fileout~.c:#include <g_canvas.h> unauthorized/mp3live~/mp3streamin~.c:#include <g_canvas.h> cheers ... tim
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
http://at.or.at/hans/
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Tue, 12 Apr 2005, Tim Blechmann wrote:
Those have their own build system. No one has added them to the externals/build setup. Ideally everything would be built there...
well, i don't think that the external build system as it is at the moment is the best way to build externals:
its the best and most stable build system that we have had. I mean its not been changed since its beginning and it is still working. compare this with the build system in pd devel and you know what i mean :)
- it doesn't handle libraries
on purpose. if one external fails to build all you loose is this external. all the rest can still be used, until it this is fixed. libraries are a bad way to organize pd externals, we should try to make it as modular as possible. this is key to collaboration.
imagine the linux kernel would be like pd, in order to get my network card running, i would have to load the coxlib, except for the eepro card, which is in the libthorvalds, which currenlty doesn,t build because of a typo in the rtl module.....
- it doesn't handle flext externals
flext has its own build system. its not the goal to handle this
- it doesn't handle special compile time flags / configure scripts / whatever
it shouldn't. special compile flags and configure are evil. make it simple and robust. the makefile for the externals has ten lines of code, not more (well someone added the ugly and completely useless optimization flags later ...).
- it's using old pd header files (0.37)
its doing this because no one updated it. So this is a bad argument from someone who is able to do so.
my 2 � ... tim
thanks for your thoughts
Guenter
-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
latest mp3: kMW.mp3 http://mattin.org/mp3.html
latest cd: Goh Lee Kwang & Tim Blechmann: Drone http://www.geocities.com/gohleekwangtimblechmannduo/
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
� wrote:
- it doesn't handle libraries
on purpose. if one external fails to build all you loose is this external. all the rest can still be used, until it this is fixed. libraries are a bad way to organize pd externals, we should try to make it as modular as possible. this is key to collaboration.
i don't understand this at all. what makes structuring code as libraries vs. singular externals a "key to collaboration" ? i mean, i cannot collaborate better or worse just because a bunch of c-files are compiled into one binary or because one c-file compiles into a bunch pd-objects.
imagine the linux kernel would be like pd, in order to get my network card running, i would have to load the coxlib, except for the eepro card, which is in the libthorvalds, which currenlty doesn,t build because of a typo in the rtl module.....
which is basically like it is ;-) to get my network card running i have to use 8139too.ko except for my wlan-card where i have to use ndiswrapper, which currently doesn't work because even windoze has no 64bit drivers for it.... (of course, we can blame broadcom to not give away there specs in the first place, but it still doesn't work)
to get you more involved: i have to compile the realtime-lsm module in order to make pd/gem work with chromium with -rt.
and most probably there is also a weird (void*)-cast error in the eepro-code of libthorvalds (although i didn't get there because of the typo in the rtl)
- it doesn't handle flext externals
flext has its own build system. its not the goal to handle this
- it doesn't handle special compile time flags / configure scripts /
whatever
it shouldn't. special compile flags and configure are evil. make it
aha
- it's using old pd header files (0.37)
its doing this because no one updated it. So this is a bad argument from someone who is able to do so.
as carmen has pointed out, no one should have to update it. imo, it is bad by design to use a local (dead) copy of a header-file when there is living one next door.
anyhow, zexy is split into one file per object to go better into the built system (for most objects; i have no idea how to handle objects like [&&~] within that context)
but still, out there in the wild there are some objects that form "natural" groups
mfg.asdr.a IOhannes
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
imo, it is bad by design to use a local (dead) copy of a header-file when there is living one next door.
I believe this is a leftover from the time, when there wasn't an "official" header in the CVS, because "devel" was HEAD.
It should be changed, shouldn't it? And this topic maybe should go to pd-dev as well.
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: "scans" _ http://footils.org/cms/show/41
On Tue, 12 Apr 2005, IOhannes m zmoelnig wrote:
what makes structuring code as libraries vs. singular externals a "key to collaboration" ?
I think it just makes it easier.
- to avoid nameclashes
- to have a common build system
- to make a list of existing externals
- to make the build system resistant to errors in single externals
- to come up with a common consistent set of externals
- make it hard to share code
wheras libraries
- make it hard to find out which externals they contain
- obscure nameclashes
- fail to build if one single external doesnt build
- have to be loaded explicitly by the user
- make it possible to share code between different objects
Therefore I think it would be better to have single externals in all cases where there is no shared code. I understand that this point of view is not shared by the other developers, I just based my decisions 2 and a half years ago on that, and that is how I explained it.
I think this enabled a very simple, robust and easy to maintain build system.
Guenter
i mean, i cannot collaborate better or worse just because a bunch of c-files are compiled into one binary or because one c-file compiles into a bunch pd-objects.
imagine the linux kernel would be like pd, in order to get my network card running, i would have to load the coxlib, except for the eepro card, which is in the libthorvalds, which currenlty doesn,t build because of a typo in the rtl module.....
which is basically like it is ;-) to get my network card running i have to use 8139too.ko except for my wlan-card where i have to use ndiswrapper, which currently doesn't work because even windoze has no 64bit drivers for it.... (of course, we can blame broadcom to not give away there specs in the first place, but it still doesn't work)
to get you more involved: i have to compile the realtime-lsm module in order to make pd/gem work with chromium with -rt.
and most probably there is also a weird (void*)-cast error in the eepro-code of libthorvalds (although i didn't get there because of the typo in the rtl)
- it doesn't handle flext externals
flext has its own build system. its not the goal to handle this
- it doesn't handle special compile time flags / configure scripts /
whatever
it shouldn't. special compile flags and configure are evil. make it
aha
- it's using old pd header files (0.37)
its doing this because no one updated it. So this is a bad argument from someone who is able to do so.
as carmen has pointed out, no one should have to update it. imo, it is bad by design to use a local (dead) copy of a header-file when there is living one next door.
anyhow, zexy is split into one file per object to go better into the built system (for most objects; i have no idea how to handle objects like [&&~] within that context)
but still, out there in the wild there are some objects that form "natural" groups
mfg.asdr.a IOhannes
Those have their own build system. No one has added them to the externals/build setup. Ideally everything would be built there...
well, i don't think that the external build system as it is at the moment is the best way to build externals:
its the best and most stable build system that we have had. I mean its not been changed since its beginning and it is still working. compare this with the build system in pd devel and you know what i mean :)
sure ... on the other hand, it's currently failing to compile some externals ;-)
- it doesn't handle libraries
on purpose. if one external fails to build all you loose is this external. all the rest can still be used, until it this is fixed. libraries are a bad way to organize pd externals, we should try to make it as modular as possible. this is key to collaboration.
imagine the linux kernel would be like pd, in order to get my network card running, i would have to load the coxlib, except for the eepro card, which is in the libthorvalds, which currenlty doesn,t build because of a typo in the rtl module.....
i know, what you mean ... still, there are externals that use shared code. the most elegant way to use this shared code is to pack externals into libraries ..
and if i build "all" externals, i want to build "all" externals, and not "all", except for toxy, pyext, cyclone, zexy ...
- it doesn't handle flext externals
flext has its own build system. its not the goal to handle this
why not? flext externals are also pd externals ... and pretty important ones...
- it doesn't handle special compile time flags / configure scripts / whatever
it shouldn't. special compile flags and configure are evil. make it simple and robust. the makefile for the externals has ten lines of code, not more (well someone added the ugly and completely useless optimization flags later ...).
hm ... i don't think, compile time flags are evil ... if i want to avoid denormals in some weird external, i haven't written, i'd like to use -mfpmath=sse -msse flags in order to do my floating point computations on the sse unit and use the DAZ feature of the hardware (that is enabled in devel)
- it's using old pd header files (0.37)
its doing this because no one updated it. So this is a bad argument from someone who is able to do so.
of course, but someone might have the idea to compile all externals against another version of pd than the latest ... imo, binding a build system to a specific version of pd, is not really the best way ...
cheers ... tim
On Apr 12, 2005, at 5:59 AM, Tim Blechmann wrote:
Those have their own build system. No one has added them to the externals/build setup. Ideally everything would be built there...
well, i don't think that the external build system as it is at the moment is the best way to build externals:
its the best and most stable build system that we have had. I mean its not been changed since its beginning and it is still working. compare this with the build system in pd devel and you know what i mean :)
sure ... on the other hand, it's currently failing to compile some externals ;-)
(in "externals/build/PLATFORM") rm failed_external.c ../src/failed_external.c make
That's all you need to do to compile the rest. Or even better, fix the
problem :-).
- it doesn't handle libraries
on purpose. if one external fails to build all you loose is this external. all the rest can still be used, until it this is fixed. libraries are a bad way to organize pd externals, we should try to make it as modular as possible. this is key to collaboration.
imagine the linux kernel would be like pd, in order to get my network card running, i would have to load the coxlib, except for the eepro card, which is in the libthorvalds, which currenlty doesn,t build because of a typo in the rtl module.....
i know, what you mean ... still, there are externals that use shared code. the most elegant way to use this shared code is to pack externals into libraries ..
The best of all worlds is to use objects as individual files that call
the shared code in a dynamic lib.
and if i build "all" externals, i want to build "all" externals, and
not "all", except for toxy, pyext, cyclone, zexy ...
- it doesn't handle flext externals
flext has its own build system. its not the goal to handle this
why not? flext externals are also pd externals ... and pretty important ones...
They have a separate build system.
- it doesn't handle special compile time flags / configure scripts / whatever
it shouldn't. special compile flags and configure are evil. make it simple and robust. the makefile for the externals has ten lines of code, not more (well someone added the ugly and completely useless optimization flags later ...).
hm ... i don't think, compile time flags are evil ... if i want to
avoid denormals in some weird external, i haven't written, i'd like to use -mfpmath=sse -msse flags in order to do my floating point computations on the sse unit and use the DAZ feature of the hardware (that is
enabled in devel)
I'll second that.
- it's using old pd header files (0.37)
its doing this because no one updated it. So this is a bad argument from someone who is able to do so.
of course, but someone might have the idea to compile all externals against another version of pd than the latest ... imo, binding a build system to a specific version of pd, is not really the best way ...
Check my other email on this topic, and the -I../../../pd/src addition
I just committed.
.hc
cheers ... tim
--
mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tklatest mp3: kMW.mp3 http://mattin.org/mp3.html
latest cd: Goh Lee Kwang & Tim Blechmann: Drone http://www.geocities.com/gohleekwangtimblechmannduo/
After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs
"The arc of history bends towards justice."
Dr.
Martin Luther King, Jr.
On Tue, 12 Apr 2005, Hans-Christoph Steiner wrote:
sure ... on the other hand, it's currently failing to compile some externals ;-)
(in "externals/build/PLATFORM") rm failed_external.c ../src/failed_external.c make
The easiest way to get the same result is to just do make -k
Guenter
libraries are a bad way to organize pd externals, we should try to make it as modular as possible. this is key to collaboration.
Sorry, i fail to understand this. Since this failure has now lasted for several years i think it won't change anymore. To my mind libraries are a valid way to organize things - i find it more convenient to have one file that contains all the bundled features than to have many files and a associated shared library that needs to be installed somewhere to be found by the system (where under Windows e.g.? in the /Winnt folder, or in pd/bin?)
- it doesn't handle flext externals
flext has its own build system. its not the goal to handle this
Well no problem. It's good than that the flext build system can handle plain PD externals.
best greetings, Thomas
Libs are easier for devs. Compiling for individual objects makes using
Pd much easier on many levels. You can have shared code when compiling
as individual files as well, just make a shared lib that each
individual object file uses.
I suppose we'll all never agree on this one, but I thought I'd throw in
my two bits.
.hc
On Apr 12, 2005, at 10:36 AM, Thomas Grill wrote:
libraries are a bad way to organize pd externals, we should try to make it as modular as possible. this is key to collaboration.
Sorry, i fail to understand this. Since this failure has now lasted
for several years i think it won't change anymore. To my mind libraries are a valid way to organize things - i find it
more convenient to have one file that contains all the bundled
features than to have many files and a associated shared library that
needs to be installed somewhere to be found by the system (where under
Windows e.g.? in the /Winnt folder, or in pd/bin?)
- it doesn't handle flext externals
flext has its own build system. its not the goal to handle this
Well no problem. It's good than that the flext build system can handle
plain PD externals.best greetings, Thomas
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it
away to benefit those who profit from scarcity."
-John Gilmore
hello pd developpers,
sorry for this disappointed question: I just cleaned (aagaiin) and apt-get installed puredata gem pd-externals on a hoary ppc (g3 pismo). I'm afraid the only way to install a "quite" functional pd on my powerbook should be to compile it by myself, by hand and needs hours again to make it working. Is it 'normal' (about apt-get ?), since it's the only ubuntu package that is not ready to work on a .deb ppc ?
thank's for your feedback,
Fred Voisin
-
cyrille -
Frank Barknecht -
FredVoisin -
g�nter geiger -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
ix＠replic.net -
patrick -
Thomas Grill -
Tim Blechmann