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

On Jan 23, 2006, at 4:03 PM, IOhannes m zmölnig wrote:

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

First off, I'd like to say that I am glad that you are looking into this. It would be huge if you and IEM join in and use Pd-extended.

Next, I have to say so of the stuff I did in Pd-extended was quick and dirty, I'll admit it. I was hoping to save some time to work on my own code ;) Hopefully each person can make the Pd-extended stuff build everything correctly, since they know the code better than me.

As for the config thing, it could work like you proposed, but then I think we might end up rewriting autoconf, which would be a waste of time. I think that if there is autoconf functionality needed, then I think we should use autoconf. I don't think it would be so hard to do, but it would take a fair amount of coordination. As for using scons, I am uncomfortable using pre-1.0 software for something as mundane as the build system. Let's keep the build system stable, since there is enough pre-1.0 code in Pd (Pd itself, portaudio, portmidi, etc. etc.).

One last thing, for objects that need extra libs, I used Günter's .libs file hack. It works fine, and is easy to do. Check these files for examples:

externals/pdogg/*/*.libs extenrals/unauthorized/*/*.libs

This target uses the .libs files:

%.$(EXTENSION): %.o $(CC) $(LDFLAGS) -o "$*.$(EXTENSION)" "$*.o" $(LIBS) \ `test -f $*.libs && cat $*.libs` \ `test -f $(dir $*)../$(BUILDSRC_OS_NAME)/$(notdir $*).libs && \ cat $(dir $*)../$(BUILDSRC_OS_NAME)/$(notdir $*).libs` chmod a-x "$*.$(EXTENSION)" $(STRIP) $*.$(EXTENSION) rm -f -- $*.o

For a more specialized setup, check out the hid targets. Also, externals/Makefile calls configure, so you could do that for now with zexy. Check out oscx, pdp, and pidip in externals/Makefile for examples. Not ideal, but works.

.hc

________________________________________________________________________ ____

"Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism." - retired U.S. Army general, William Odom