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

Hans-Christoph Steiner hans at eds.org
Tue Jan 24 07:49:49 CET 2006


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





More information about the Pd-dev mailing list