[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