I just downloaded the latest CVS of pd, but there isn't even an autogen.sh or configure script to run and get the build going.
is CVS on sourceforge still being maintained?
is there a more preferable way to install PD?
thanks -august.
On 14/11/2006, at 17.51, august wrote:
I just downloaded the latest CVS of pd, but there isn't even an autogen.sh or configure script to run and get the build going.
Did you check /path/to/pure-data/pd/ for either INSTALL.txt or
README.txt?
In the INSTALL.txt it says:
Change to "src" subdirectory.
type "./configure", possibly adding flags as follows:
To enable ALSA 0.9x (the latest one), add "--enable-alsa".
To enable the older ALSA 0.5x, add "--enable-old-alsa".
To enable Ritsch's RME 9652 driver, add --enable-rme".
To put Pd in /usr/bin instead of /usr/local/bin, add "--prefix=/
bin".
Type "make depend" and then "make"; or, if you prefer, as superuser type "make install".
The README.txt points to the manual which is online at MSP's site: http://www.crca.ucsd.edu/~msp/Pd_documentation/x3.htm#s1.2
is there a more preferable way to install PD?
LIke getting a pre build Pd? Check http://puredata.org/downloads/
Steffen wrote:
On 14/11/2006, at 17.51, august wrote:
I just downloaded the latest CVS of pd, but there isn't even an autogen.sh or configure script to run and get the build going.
Did you check /path/to/pure-data/pd/ for either INSTALL.txt or README.txt? In the INSTALL.txt it says:
Change to "src" subdirectory.
type "./configure", possibly adding flags as follows:
the problem is, that in the CVS there is no "configure" file in ./src (and it is also missing in recent source tarballs)
you have to generate it first, by running "autoconf" (obviously you need to have autoconf installed on your system)
mfga.dr IOhannes
On 14/11/2006, at 17.51, august wrote:
I just downloaded the latest CVS of pd, but there isn't even an autogen.sh or configure script to run and get the build going.
Did you check /path/to/pure-data/pd/ for either INSTALL.txt or README.txt? In the INSTALL.txt it says:
Change to "src" subdirectory.
type "./configure", possibly adding flags as follows:
the problem is, that in the CVS there is no "configure" file in ./src (and it is also missing in recent source tarballs)
exactly.
you have to generate it first, by running "autoconf" (obviously you need to have autoconf installed on your system)
there used to be an autogen.sh script that would do all the autoconf stuff for you. I played with it for about a half hour, using a couple of different versions of autotools and got nowhere.
Any reason why this "autogen.sh" is not included?
-august.
august wrote:
you have to generate it first, by running "autoconf" (obviously you need to have autoconf installed on your system)
there used to be an autogen.sh script that would do all the autoconf stuff for you. I played with it for about a half hour, using a couple of different versions of autotools and got nowhere.
Any reason why this "autogen.sh" is not included?
which version of pd do you try to build?
"autogen.sh" was never part of vanilla pd. furthermore, it does not seem to be a "standard way" to build a software package to me ("standard" being one of: "make" or "./configure && make" or "autoconf && ./configure && make" or "aclocal && autoconf && ./configure && make")
the way to build vanilla pd, is: ~> cd ...pd/src ~> autoconf ~> ./configure ~> make ~> sudo make install
however, "autogen.sh" used to be part of pd-devel. afaik, this has been replaced by a scons-based build system. the way to build pd-devel (including desire data) is: ~> cd ...pd/src ~> scons
(use "scons -h" and/or "scons -H" to find out more about scons)
mfg.adr IOhannes
you have to generate it first, by running "autoconf" (obviously you need to have autoconf installed on your system)
there used to be an autogen.sh script that would do all the autoconf stuff for you. I played with it for about a half hour, using a couple of different versions of autotools and got nowhere.
Any reason why this "autogen.sh" is not included?
which version of pd do you try to build?
I just checked out a fresh cvs from sourceforge.
"autogen.sh" was never part of vanilla pd.
it used to be included in the cvs afair.
furthermore, it does not seem to be a "standard way" to build a software package to me ("standard" being one of: "make" or "./configure && make" or "autoconf && ./configure && make" or "aclocal && autoconf && ./configure && make")
I would go with just ./configure && make
autoconf and automake have so many different versions at this point.
the way to build vanilla pd, is: ~> cd ...pd/src ~> autoconf ~> ./configure ~> make ~> sudo make install
thanks
however, "autogen.sh" used to be part of pd-devel. afaik, this has been replaced by a scons-based build system. the way to build pd-devel (including desire data) is: ~> cd ...pd/src ~> scons
ok, many thanks ... but, I just downloaded the pd-0.38-4-devel-2.tar.bz2 from sourceforge (linked from puredata.info) and it still has the configure, make system.
seems to compile ok now, though.
(use "scons -h" and/or "scons -H" to find out more about scons)
vielen dank -august.
You might also be interested in nightly builds:
http://autobuild.puredata.info
.hc
On Nov 14, 2006, at 7:30 PM, august wrote:
you have to generate it first, by running "autoconf" (obviously
you need to have autoconf installed on your system)there used to be an autogen.sh script that would do all the
autoconf stuff for you. I played with it for about a half hour, using a
couple of different versions of autotools and got nowhere.Any reason why this "autogen.sh" is not included?
which version of pd do you try to build?
I just checked out a fresh cvs from sourceforge.
"autogen.sh" was never part of vanilla pd.
it used to be included in the cvs afair.
furthermore, it does not seem to be a "standard way" to build a
software package to me ("standard" being one of: "make" or "./configure &&
make" or "autoconf && ./configure && make" or "aclocal && autoconf && ./configure && make")I would go with just ./configure && make
autoconf and automake have so many different versions at this point.
the way to build vanilla pd, is: ~> cd ...pd/src ~> autoconf ~> ./configure ~> make ~> sudo make install
thanks
however, "autogen.sh" used to be part of pd-devel. afaik, this has been replaced by a scons-based build system. the way to build pd-devel (including desire data) is: ~> cd ...pd/src ~> scons
ok, many thanks ... but, I just downloaded the pd-0.38-4-devel-2.tar.bz2 from sourceforge (linked from
puredata.info) and it still has the configure, make system.seems to compile ok now, though.
(use "scons -h" and/or "scons -H" to find out more about scons)
vielen dank -august.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either
change them, or perish. -William Carlos Williams
august wrote
which version of pd do you try to build?
I just checked out a fresh cvs from sourceforge.
this is not sufficient information to guess the flavour of pd. pd-vanilla is the MAIN trunk of the cvs on sourceforge. pd-devel is branched away from this trunk (in a branch called pd_devel_0_39 (or so))
"autogen.sh" was never part of vanilla pd.
it used to be included in the cvs afair.
again, it was _never_ part of vanilla pd. it was part of pd-devel, which is in the same cvs (see above).
i am not entirely sure, but it might be that in very former times, before miller started to use the sourceforge CVS for vanilla pd, the MAIN branch was actually a version of pd-devel (possibly including autogen.sh)
furthermore, it does not seem to be a "standard way" to build a software package to me ("standard" being one of: "make" or "./configure && make" or "autoconf && ./configure && make" or "aclocal && autoconf && ./configure && make")
I would go with just ./configure && make
this has been discussed at length (see the pd-dev archives). "configure" is considered a "binary" (generated code), made from configure.in (or configure.ac) by autoconf. each change of configure.in results in a change of configure, therefore you would have to maintain 2 different views of the same information via cvs. each run of autoconf will produce a new version of "configure" (with dates changing)...
autoconf and automake have so many different versions at this point.
true, though i must confess that i never had problems with such a simple configure.in like the one in pd (afaik, it doesn't use any specifics of autoconf versions).
and after all, the "autobuild.sh" script, really just did this: call "automake && autoconf", probably with versions attached to the command-names, which usually broke my build system since i had not installed the very same version of automake/autoconf as the original author of autogen.sh, and so the commands could not be found; changing the autogen.sh script to match my versions solved this (my version of autoconf/automake could still produce a valid configure script). so personally i think the autogen.sh caused more trouble than it fixed.
ok, many thanks ... but, I just downloaded the pd-0.38-4-devel-2.tar.bz2 from sourceforge (linked from puredata.info) and it still has the configure, make system.
i was referring to the CVS version of pd-devel. probably there is even an autoconf build system for pd-devel in CVS, but i doubt whether it is still maintained.
mfg.adr IOhannes
On Wed, 15 Nov 2006, IOhannes m zmoelnig wrote:
pd-devel is branched away from this trunk (in a branch called pd_devel_0_39 (or so))
just devel_0_39
i was referring to the CVS version of pd-devel. probably there is even an autoconf build system for pd-devel in CVS, but i doubt whether it is still maintained.
There is not, but I wouldn't hate one. I don't know how long I'll keep using scons: it seems like too much to learn for almost no benefit over "make". However, I'll stick with scons until I have enough reasons to switch back to "make".
Here's one reason to not use scons: it claims that I don't have Tcl 8.5; then I open config.log, I see:
gcc -c -o .sconf_temp/conftest_9.o .sconf_temp/conftest_9.c gcc -o .sconf_temp/conftest_9 .sconf_temp/conftest_9.o -ldl -ljack -lasound -lm -ltcl8.5
/usr/bin/ld: cannot find -ltcl8.5
So, I paste the 2nd commandline straight in the terminal, and there, it compiles without any error.
This means that gcc is ignoring the following environment variable:
LIBRARY_PATH=/home/matju/lib
Which it will only ignore if it's just not there - so maybe scons is removing it. In any case, scons doesn't have my permission to remove LIBRARY_PATH from the environment.
And then, i've had conflicts (crashes?) between pd devel and my new tcl.pd_linux if it's compiled with a different tcl, but at the moment I can't reproduce the problem.
Besides, devel_0_39 doesn't need to be linked to tcl server-side; only t_main.c and t_tkcmd.c are using libtcl, and t_*.c are the client side. But somehow many versions of pd over the years link tcl and tk on the server side. I remember that in OSX it was the reason why GridFlow's [#out x11] couldn't work, because libtk embedded a customised libX11 that wasn't fully compatible with the standard libX11. Well, it still can't work on OSX because that linkage problem is still there.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada