[PD-dev] Build integration (was: Re: any2string problem)

[Bryan Jurish]

moin all,

On 2007-08-02 04:28:44, Hans-Christoph Steiner <hans at eds.org> appears to
have written:
> On Aug 1, 2007, at 1:30 AM, IOhannes m zmoelnig wrote:
>> i simply cannot keep track whether my changes to my code affect all of
>> these systems. i am happy if it compiles with mine.

Right.  So what we need (im(ns)ho) is a least-common-denominator sort of
way to dispatch to variant build systems.

> I couldn't agree more, we should have one build system for  
> everything.  Right now, the only functional option for that is the  
> current Pd-extended build system.

Agreed.  Hence my long-intended stay-up-late-hacking session yesterday,
during which I believe to have snuck (most of) my externals into the
pd-extended system.  The tricks I used rely on the pd-extended build
using GNU make, but it looks like there are a number of other GNU-isms
in externals/Makefile, so I feel safe there (feel free to object, of
course).  I wound up (mostly) just delegating the build from the
"moocow" targets in externals/Makefile to conventional targets ("build",
"install", "clean") in externals/moocow/extended/Makefile, which in turn
just call (./autogen.sh; ./configure; make; make install) with
(hopefully) suitable arguments.  The same basic technique could be made
to work more systematically, *especially* if GNU make is ensured ($(eval
$(call ...)) is your friend!)

One thing I'm uncertain of (never having built the whole pd-extended
from scratch) is what is supposed to live in the $(pd_src) variable; or
rather, where "m_pd.h" is supposed to live in relation to $(pd_src)/.
I've gone with the assumption that m_pd.h lives in $(pd_src) directly.
Please let me know if I should use e.g. $(pd_src)/src instead.

>> http://puredata.info/Members/zmoelnig/pdcon07/BuildIntegration

I've added a few thoughts to this page -- I hope you don't mind.  In
particular, one of the major itches I've had when compiling a new pd
version or installing on a new machine is the lack of unified
conventions for handling machine-specific optimization flags ("-march="
and friends).  I think that any specification for a new|old|hybrid build
architecture should take this into account, at best without requiring
users to edit a file that itself lives in CVS.  Thomas Grill's flext
system is one way to handle this sort of thing, but I'd most like to see
it handled by environment variables (e.g. CFLAGS, or maybe PD_CFLAGS)
and make's "?=" and "+=" operators... again, feel free to object and to
kick my wiki paragraph into /dev/null if you think that's where it
belongs...

Of course, any CFLAGS passed down from the "global" build options might
get lost, clobbered, or just ignored by local builds: that should be
allowed, but I'd like to motion for the establishment of some convention
here.

marmosets,
	Bryan

-- 
Bryan Jurish                           "There is *always* one more bug."
jurish at ling.uni-potsdam.de      -Lubarsky's Law of Cybernetic Entomology