(Following up on the thread "[EE]: how to report an error from (GNU) makefile".) For most here, build scripts is probably not an issue. Either you use an IDE that includes that functionality, or you just build the full project when you need to build. But when working in a company or professional setup, release management becomes a bit of an issue. Version control tools and build management tools can be quite helpful. > While I second Peter's suggestion to RTM, I also know that the makefile > syntax is not really intuitive, and the manual only helps some. I'm > actually looking (with a low priority) for better alternatives. So far I've > looked at Ant and Jam > . A pretty good summary of issues around build tools can be found here: http://www.scons.org/wiki/FromMakeToScons http://www.scons.org/wiki/SconsVsOtherBuildTools As these links may indicate, SCons is my current choice (of Make, Ant, Jam and SCons). I think over time I'll move towards it (from the mixture of shell scripts and makefiles I'm currently using). The main reasons: - Written in a widely ported script language (Python). Runs on all platforms I can see me working in the foreseeable future. (SCons, Ant. To some degree Jam and Make.) - The "makefiles" are a sort of Python program -- not really programs, but they allow nevertheless use of Python constructs if necessary. Powerful enough to do pretty much everything I may need. (Ant, in some ways.) - While targeted towards more "normal" system development, it's flexible enough to be used for anything embedded. (All.) - Contains out of the box version control integration, which allows the build script to control the checkout of the source files. Helpful for builds of specific tags or for setting up new team members. (SCons.) - If (when) the need arises to extend the functionality, this will have to be written in Python -- and not in yet another specific language. (Ant.) - Has an automatic dependency scan for C/C++. Additional scanners can be integrated -- in Python. (Jam.) - Tracks file changes through content signatures rather than file timestamps. This behavior of make is the reason why some version control systems (like cvs) set the file modification date on checkout to the current date rather than to the checkin date (which for many users is much more intuitive, and in many cases is much more useful). SCons's use of content signatures allows use of the checkin date on checkout (that's an option for cvsnt, for example). (SCons.) > Ant is Java-based and I'm not sure whether it'll be easier in the end -- I > have yet to see a C-type build setup with Ant. It seems to be very > universal -- with the associated (dis)advantages. It seems I'm not the only one to have felt the lack of a C-type build task in Ant. Here is one: http://ant-contrib.sourceforge.net/cc.html Looks attractive, but my feeling is that there's too much to do and the learning curve is too steep to get it where I want it. > Jam seems to be something that is worthwhile looking into, but I haven't > yet had the time. It seems to be specifically targeted towards C/C++, even > though it probably can be (ab)used for other purposes, too. Original Jam (Perforce): http://www.perforce.com/jam/jam.html FTJam: http://freetype.sourceforge.net/jam/ Boost.Jam: http://www.boost.org/tools/build/v1/build_system.htm Looks also attractive. The main reasons I ditched this in favor of SCons are that anything more complex that needs to be scripted can be scripted in Python and not in something proprietary and that SCons uses content signatures for dependencies (rather than timestamps like Jam). Gerhard -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist