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