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

[Hans-Christoph Steiner]

On Aug 2, 2007, at 4:12 PM, Bryan Jurish wrote:

> 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.


The global variables $(pd_src) are defined in packages/ 
Makefile.buildlayout:

pd_src = $(cvs_root_dir)/pd

so m_pd.h is in $(pd_src)/src

>
>>> 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.

We should use a standard method for this kind of thing, like  
autoconf.  This would another advantage of a unified build system.   
This mostly works with Pd-extended now, but it could be handled much  
better.

.hc


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



------------------------------------------------------------------------ 
----

All information should be free.  - the hacker ethic