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