[PD-dev] Re: externals/build SConscript

Tue Nov 1 06:48:29 CET 2005

On Oct 31, 2005, at 11:18 PM, carmen wrote:

> On Mon, Oct 31, 2005 at 08:05:01PM -0500, Hans-Christoph Steiner wrote:
>>
>> Its unfortunate that we have two build systems that do the exact same
>> thing.
>
> not true..the 'make' script builds single C sources which have been  
> aliased into the build/src/ dir, the SCons script builds those as well  
> as various libraries that i liked. theres no extra work to support  
> both if you put the files in build/src..

Well, that has nothing to do with scons or make, its a design decision.  
  Any build system could do both single files, libs, or both.

> some systems have python and not autotools, and vice versa..

But generally, any system can have either installed, thanks to them  
being free software.

>
>> It would be nice if all that effort went into one build system
>> that was really good, instead of making a new one that duplicates the
>> old one.
>
> not true if by 'old one' you mean /externals/build/{platform} (3  
> seperate systems) - but it is duplicating/replacing build scripts of  
> individual libraries, which could get out of synch over time...somehow  
> SConscripts seemed more robust than scripting a 'make' via exec()..but  
> given gentoo's very successful approach in doing that, it could be  
> considered..

The libraries should be deprecated where ever possible, instead we  
should use a common build system.  That will save everyone a lot of  
time.  The one in externals/build works well, no its not perfect, but  
its there and it works.

> but really, read the cyclone makefile and tell me you know what its  
> doing! i had to rewrite it in SCons just to figure out how everything  
> fit together..

But you don't need to understand it if it works, just use it.  I  
certainly don't understand everyone's build system.  SConscript makes  
even less sense to me since I have little experience with it, but I am  
sure I could call it from a Makefile if someone gave me the command  
line.  But I am not interested in whether make or scons is better.   
What is in place works.  If it ain't broke, don't fix it.

>>  This is all stuff that was covered years ago in the
>> makefiles.
>
> could you type 'make' once and get zexy, cyclone, pdcontainer, ann,  
> pmpd, unauthorized, OSCx, etc? i dont think you could..

You should try the Pd.app build system (packages/darwin_app/Makefile).   
You type 'make' once and you get Pd, externals, comport, iemlib, ggee,  
hid, pmpd, unauthorized, cyclone, OSCx, Gem, PDDP, RRADical, maxlib,  
flext, docs/tutorials/abstractions from CVS, toxy, etc.  Any now Jamie  
just added PDP, pdp2gem and pix_2pdp to that too. It would be great to  
also have PdContainer and ann to that as well.  But instead we have a  
second build system that doesn't do as much.

Anyway, I'll be working on porting the Pd.app build system to Windows  
and Linux this month, so then we'll have a unified build on all three  
platforms.  I'd love any help, the build system so far has been very  
much a group effort, and more we join forces, the better it'll get.

.hc

>> But I guess that's open source.  People are welcome to do whatever
>> floats their boat. I am certainly not going to stop anyone.
>
> me neither :) feel free to add iemlib or anything else you think is  
> missing..an ebuild to grab all the dependencies would be nice as  
> well..
>
> c
>>
>> .hc
>>
>> On Oct 28, 2005, at 9:09 AM, Lorenz Schori wrote:
>>
>>> hi
>>>
>>> i've done a little work on the SConscript in external build system to
>>> better support osx:
>>> - define MACOSX for osx builds (for miXed)
>>> - remove -dynamiclib from SHLINKFLAGS and add -bundle and
>>> -bundle_loader ../../pd/bin/pd
>>> - fink and darwinports locations are added to CPPPATH and LIBPATH if
>>> they exist
>>> - search for *.libs files in win/darwin/linux and after in src
>>> directory and add the flags
>>>
>>> - some few externals still don't compile because of missing libraries
>>> and .libs or minor include problems.
>>>
>>> perhaps we could introduce some static link option (i'm not sure if
>>> i'd like statically linked externals). another possibility would be  
>>> to
>>> just grep for the used libraries (*.libs) and bundle them with the
>>> externals or with pd.app (not quite trivial. see:
>>> http://qin.laya.com/tech_coding_help/dylib_linking.html).
>>>
>>> lorenz
>>>
>>> <SConstruct>
>>
>> ______________________________________________________________________ 
>> __
>> ____
>>
>> Using ReBirth is like trying to play an 808 with a long stick.
>>
>>          -David Zicarelli
>>
>>
>> _______________________________________________
>> PD-dev mailing list
>> PD-dev at iem.at
>> http://lists.puredata.info/listinfo/pd-dev
>
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev
>

________________________________________________________________________ 
____

"[W]e have invented the technology to eliminate scarcity, but we are  
deliberately throwing it
away to benefit those who profit from scarcity."

        -John Gilmore