[PD-dev] Re: externals/build SConscript

[Hans-Christoph Steiner]

On Nov 1, 2005, at 6:45 AM, Frank Barknecht wrote:

> Hallo,
> Tim Blechmann hat gesagt: // Tim Blechmann wrote:
>
>> imo, someone should look into it and write a platform independent
>> scons Builder then we wouldn't have this nasty discussion any more.
>
> Trying to get the discussion back from nasty and on to some more
> technical stuff: Without any offence intended I don't think the
> traditional build system was working perfecly well, and in some
> regards it ways really hitting at walls. It is great for what it tried
> to be great at, that is, building single externals, which are not
> using (many) libraries and which are written in C. It has problems
> with externals using several source files or externals written in C++
> in certain areas.

First off, I had no intention of being nasty, or a desire to be. I am  
sorry if I came across that way. I just get depressed that our limited  
dev resources are spent reinventing the wheel.  The externals/build  
system isn't perfect, but that doesn't mean it can't be made better  
without being totally discarded.  But it does work well, and on all  
platforms with standard tools that basically all developers use and  
know enough about.

And yes, there should be a separate C++ build system.  And there is  
with flext.

> Others (carmen etc.) also thought the "build" was limited and as
> action speaks louder, they just made a new one without breaking the
> old one. That's fine. (Btw: There also is the flext-buildsys, a third
> try to get over all the difficulties with building stuff for different
> platforms.)

It just takes some communication, then we can work together.  Or we  
could go back to the pre-CVS days where everyone just wrote their own  
stuff totally separately, and if you wanted to use it, you had to  
figure out a each person's build system, deps, etc.

> We could discuss (again) if libraries are good or bad, however even
> scons tries to build as much as possible as single externals (e.g. it
> builds Zexy that way).  Scons however makes it easier to also get
> libraries into the build and as Tim noted it also can be used to build
> C++/flext externals like PDContainer or pool.

externals/build already builds zexy as single externals.   
packages/darwin_app/Makefile builds libs as well, like pmpd.  Most of  
what's in packages/darwin_app/Makefile is just basic makefile stuff, so  
it will be an easy port to Linux and MinGW/Windows.

> What I think is impressive about scons, is that it doesn't require
> that much work to get new externals into the build system. It is not
> strictly necessary to #include-link files into "build", instead also a
> "SConscript" in (selected) source directories can be used.

> I don't like at all, that the main SConscript deletes stuff from build
> locally and that it does so using platform dependent sh instructions.
> That's not the way a build system in CVS should work. Maybe it would
> be possible to find a cleaner solution to conflicting externals.

> Also the way it is set up should be better documented than just
> "scons; scons install". Things like how to set an install prefix
> should be explained as well as how to add new externals to the scons
> build. This is an area, where the traditional build is much better.

Its quite simple to add a new C external to externals/build, usually it  
consists only of adding the .c link file to externals/build/src and the  
documentation files to externals/build/doc/makefile.  Check out  
externals/build/README for documentation on how to add yours.

Adding new externals, abstractions, libs, docs, tutorials, etc. to  
packages/darwin_app/Makefile is also relatively easy, you basically  
just add the command lines that you would type to compile and install  
that set of externals.  It does need better documentation, but there is  
some already.

I haven't really used flext, so I can't speak to that.

> However I do think, that scons could actually be the more flexible
> solution to get all the different build preferences of every developer
> together. So I'd like it if we could discuss this openly.

Like I said, I am not going to stop anyone.  But its just a shame that  
work is going into a  new build system that is just duplicating  
existing functionality.  Instead, if that same amount of effort had  
been put into the existing system, then we'd have a much better system  
than either of the ones that exist now.

make isn't perfect, but its something that basically all C developers  
know enough about.  Personally, I've never used python, so its much  
less attractive to me.  The last thing I want to do spend time learning  
yet another build system when the current one works.

.hc

>
> Ciao
> --  
>  Frank Barknecht                 _ ______footils.org_ __goto10.org__
>
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev
>

________________________________________________________________________ 
____

If you are not part of the solution, you are part of the problem.
                                                                          
                            - Eldridge Cleaver