Your favorite source build system (for C++)

This is a discussion on Your favorite source build system (for C++) within the Tech Board forums, part of the Community Boards category; Hi, What build system do you like most and for what main reason? Has anyone experiences with SCONS? I've only ...

  1. #1
    Registered User
    Join Date
    Nov 2006
    Posts
    519

    Your favorite source build system (for C++)

    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.

  2. #2
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    Quote Originally Posted by pheres View Post
    What build system do you like most and for what main reason?
    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.

  3. #3
    CSharpener vart's Avatar
    Join Date
    Oct 2006
    Location
    Rishon LeZion, Israel
    Posts
    6,484
    Quote Originally Posted by brewbuck View Post
    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.
    VS project file is also just another file that you can (should?) versioncontrol
    The first 90% of a project takes 90% of the time,
    the last 10% takes the other 90% of the time.

  4. #4
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    Quote Originally Posted by vart View Post
    VS project file is also just another file that you can (should?) versioncontrol
    I don't use VS except to compile, but don't most people use more elaborate configuration management packages than just basic project files?

    I'm not disparaging VS, I don't have much knowledge of it.

  5. #5
    & the hat of GPL slaying Thantos's Avatar
    Join Date
    Sep 2001
    Posts
    5,681
    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.

  6. #6
    Registered User
    Join Date
    Nov 2006
    Posts
    519
    Quote Originally Posted by brewbuck View Post
    GNU make, because it takes about five seconds to set up.
    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?

  7. #7
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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.
    Last edited by CornedBee; 02-12-2008 at 12:58 PM.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  8. #8
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    Quote Originally Posted by pheres View Post
    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?
    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:

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

  9. #9
    Registered User
    Join Date
    Nov 2006
    Posts
    519
    Quote Originally Posted by CornedBee View Post
    Boost.Build for C++. Its configuration management and sanity across platforms far outweighs its considerable learning curve.
    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.

    On my machine, make needs several minutes of creating recursive processes just to determine that my Mozilla tree is up to date.
    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

  10. #10
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,604
    I've never really needed such fine control so Visual Studio's build system has been enough for me.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  11. #11
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    IIRC it's bad practice to use make in a recursive manner
    Perhaps, but that's what the autotools do.

    if you don't intend to rewrite the make scripts for the whole mozilla tree
    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.
    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.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  12. #12
    Registered User
    Join Date
    Nov 2006
    Posts
    519
    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?
    Last edited by pheres; 02-12-2008 at 03:48 PM.

  13. #13
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    sys 0m36.687s

    sys 0m11.099s
    Not pointless. I think it quite clearly shows how much time is wasted during process creation.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  14. #14
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,046
    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.
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  15. #15
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    Quote Originally Posted by dwks View Post
    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.

    Code:
    .depend: $(SRCS) $(HDRS)
        $(CXX) $(INCLUDE) -M $(SRCS) > .depend
    
    -include .depend
    Is pretty much all it takes.

Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Tutorial review
    By Prelude in forum A Brief History of Cprogramming.com
    Replies: 11
    Last Post: 03-22-2004, 08:40 PM
  2. Request for comments
    By Prelude in forum A Brief History of Cprogramming.com
    Replies: 15
    Last Post: 01-02-2004, 09:33 AM
  3. DirectX Worm! (source included)
    By Jeremy G in forum Game Programming
    Replies: 5
    Last Post: 03-12-2003, 02:08 AM
  4. fopen();
    By GanglyLamb in forum C Programming
    Replies: 8
    Last Post: 11-03-2002, 11:39 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21