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