(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