Hans-Christoph Steiner wrote:
Hey,
Right now, in the 'externals' section, there are many build systems for different sections that reflect the build systems that the given dev used before importing the code into CVS. A couple of these use their own private autoconf setups (pdstring, pdp, pidip, zexy, OSCx, and probably others). I personally think that there should be one central autoconf system for everything.
my personal problem with this (as explained at length before), is that i desperately want an external to be self-contained (apart from obvious dependencies like the pd-headers).
for me this implies the build-system to be modular and not depend on a an up-level configuration. e.g. if i want to build "aconnect" external that lives in externals/iem/aconnect/ then i do not want to have to checkout externals/Makefile and what else and depend on a deep directory structure. it should be enough to get externals/iem/aconnect/ and be able to compile the external (without having to know all the compiler and linker flags by heart)
i think this is really essential for my use of the externals.
having said all that, this doesn't mean that i think it a bad idea to provide information in a centralized manner. the key point however is that the information should be provided to be pulled from a certain external's build-system rather than pushed to it.
what i mean by this is: each external should have a self-contained build-system that is able to build the external without any up-level dependencies. however, this build-system should respect environmental variables that are set by an up-stream configuration process, and which is therefore able to guarantee that all externals are actually configured the same way.
i don't know yet, how we could handle this generically for a master include-file. (config.h)
btw, before the pd-convention i have setup a wiki to discuss exactly this issues http://puredata.info/Members/zmoelnig/pdcon07/BuildIntegration/
mfg.asdr IOhannes