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.