Printable View
Hi,
What build system do you like most and for what main reason? Has anyone experiences with SCONS?
I've only used gnu make which can become horrible complex, Eclipse-CDT built-in system and the VS2005 build-in which I found really painfull to setup through the VS-GUI because of the tiny edit-boxes or the macros which only sometimes can be inserted through clicking.
GNU make, because it takes about five seconds to set up. You edit the build with a text editor instead of some fancy GUI, but I like that. The makefile is just another file in the source tree, so you can version control it just like anything else.Quote:
Originally Posted by pheres
VS project file is also just another file that you can (should?) versioncontrolQuote:
Originally Posted by brewbuck
I don't use VS except to compile, but don't most people use more elaborate configuration management packages than just basic project files?Quote:
Originally Posted by vart
I'm not disparaging VS, I don't have much knowledge of it.
I tend to use make. Yes it can be horribly complex but once you've setup a shell then it is real easy to apply it to another program. Though I'm still working on how to make the Makefile be part of the dependency along with a good system for header files requiring other header files.
I know a guy who is much deeper into gnu make than I probably ever will be and he did spend 2..3 nights to set it up so it worked transparently with 2 compilers (gcc+mingw) for a medium project. He integrated macros which can be used to build shared libs, static libs or executables. It works realy great, but for me it was really hard to read, adapt and debug. There must be something better which has equal power, mustn't it?Quote:
Originally Posted by brewbuck
Boost.Build for C++. Its configuration management and sanity across platforms far outweighs its considerable learning curve.
I've also used SCons. It's a very nice tool, as I remember, although I didn't do much. It was another team member who set it up.
Although you didn't ask for it, I use Apache Ant for Java.
Make annoys me. On my machine, make needs several minutes of creating recursive processes just to determine that my Mozilla tree is up to date. I don't have a benchmark to back this up, of course, but I'm pretty sure non-recursive build systems like SCons or BB would be some orders of magnitude faster at that.
I use make only for trivial projects. For everything beyond that, you'd need automake (edit: or something like brewbuck's setup), which I consider the antichrist of build systems.
That sounds like more work than necessary. My basic make system is based on a series of template files. Creating a new project basically involves copying the template and filling in a few blanks. The template supports:Quote:
Originally Posted by pheres
* Automatic dependency building
* Automatic switching between debug, release, and profile modes (without making subtle errors) all from the make line
* Recursive making of sub-modules when code is organized into a directory structure
I admit this all took more than "five seconds" to write but once written it is easy to use everywhere. Think of it as a very, very simplified version of autoconf.
That wakes up memories about how I liked to build boost on different plattforms. It was really convenient. So I think I will look into Boost.Build at first.Quote:
Originally Posted by CornedBee
IIRC it's bad practice to use make in a recursive manner, because this can lead to the problem you described as well as several others (rebuilding unneeded stuff and so on). So it may help to use make in a single session with make-modules for your software modules instead of seperate makefiles. Ok, but this will not help you, if you don't intend to rewrite the make scripts for the whole mozilla tree ;)Quote:
On my machine, make needs several minutes of creating recursive processes just to determine that my Mozilla tree is up to date.
I've never really needed such fine control so Visual Studio's build system has been enough for me.
Perhaps, but that's what the autotools do.Quote:
IIRC it's bad practice to use make in a recursive manner
The Mozilla build system is hell on earth, but that applies equally to most large open-source projects. OpenOffice.org's is even worse. X.org rewrote theirs a few years ago from scratch. KDE scrapped theirs in 3.4, I think.Quote:
if you don't intend to rewrite the make scripts for the whole mozilla tree
The problem with rewriting the thing is
1) It's a HUGE effort.
2) Nobody will really care, because it works now.
3) You'd never get a consensus on the build system to use. Unless you use plain make. And I definitely won't rewrite anything in plain make. :)
Kde seems to stick to autotools until 3.5.8 and switches to cmake with 4.0.
To spice the thread, here the absolutely pointless speed comparison done a couple of minutes ago on my system building
kmix-3.8.5 (autotools)
real 1m27.553s
user 1m17.888s
sys 0m36.687s
vs.
kmix-4.01 (cmake):
real 0m54.506s
user 1m6.345s
sys 0m11.099s
Any non-pointless opinions about cmake?
Not pointless. I think it quite clearly shows how much time is wasted during process creation.Quote:
sys 0m36.687s
sys 0m11.099s
Also note that if you add those numbers together, you get 202.128 for the former and 131.95 for the latter. In other words, even though kmix-4.01 is a more recent version and likely more complicated, cmake was much faster than autotools to build it.
I'm not sure what this means, I'm just making an observation. :)
Personally, I use make. I read the info page for make for about two hours straight, and then wrote up a reasonable makefile that I use in several of my projects. It's not bad; you can see an example of it for xuni. However, it uses a depend file to keep track of dependencies, which you have to update yourself by typing make clean ; make. (I didn't want a file.d for every source file, and other solutions didn't seem to be forthcoming -- besides generating it every time.) For that and other reasons, I've also been looking into a new build system.
Either you have a separate dependency record for each source file, or you have to re-run the depend every time a file changes. I really can't think of any way around that. Personally, I just re-run the dependency builder (or rather, the makefile does this for me) whenever anything changes. If this involves lots and lots of modules, I start breaking things into libraries to prevent the dependency multiplication, which is a good thing anyway.Quote:
Originally Posted by dwks
Is pretty much all it takes.Code:.depend: $(SRCS) $(HDRS)
$(CXX) $(INCLUDE) -M $(SRCS) > .depend
-include .depend
The reason I've chosen kmix was, besides it's tininess, the fact that the functionality is about the same in both versions. Many other kde programs made one or two steps back in terms of functionality while being advanced to version 4 by the way.