moin all,
On 2007-08-02 04:28:44, Hans-Christoph Steiner hans@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