[PD-dev] Re: new zexy build system breaks pd-extended inclusion

[IOhannes m zmölnig]

Hans-Christoph Steiner wrote:
> 
> You might be interested in this, too, as an easy way to test building  
> zexy with the build system:
> 
> cd externals && make zexy
> 
> externals/Makefile has a separate zexy target now which compiles the  
> files directly in externals/zexy/src.
> 

i just played a bit with the pd-extended build system (as you might see 
in todays's CVS-logs coming tomorrow - things like changing the spelling 
of my name and the like)

it seems to work fine, however some things are not clear to me (if i use 
zexy-objects in the example below, please forgive me, but they are kind 
of close to me)
as far as i can see it, certain assumptions are made about the setup of 
the builing OS.
there are no tests whether things (files, libraries) exist.
while this makes the build-system simple and easy, it only allows for 
the most generic objects to be built (those that depend on libc, libm 
and the like)
however, often things are not that easy (and that's why people have 
invented configuration systems like autoconf and SCons and i don't know 
what)

furthermore it might be good to provide a mechanism that would allow 
developers to adapt the build-system to their needs (since they are 
supposed to know most about their code), with reasonable fallbacks if 
they provide none.

e.g. i noticed that while zexy was mainly built (some objects were 
missing which i would consider crucial, like [z~] - which unfortunately 
starts with a 'z'...), several objects were built in a rough-and-ready 
manner. e.g. [lpt] (which people have reported to be useful) is compiled 
- but without parallel-port support; while this is ok on macintosh (due 
to the lack of a parallel-port), i don't like it on PCs.
when using the zexy-build-system, i take care of this via autoconf.
i take care of several other things via autoconf too, that is why i 
(additionally) introduced zexyconf.h.


therefore, it would be nice to be able to do some "configuration" for 
each library and/or to modify the build-process locally.

1st thing could be done by providing a "config" target in the Makefile.
eg "make zexy_config" would run the autoconf stuff (or something 
apropriate), while "make iem16_config" would do nothing.

2nd thing could be done by searching the library-paths for a localized 
Makefile (like Makefile.extbuild) which would/could overwrite (parts of) 
the default values given in the externals/Makefile.
these Makefiles could then be maintained by the original authors (if 
they care to do so; if not, there would be no such Makefiles)

bad ideas? chaotic? just thinking

mfg.adsr
IOhannes