I've just released a build tool (TCBuild) that I developed especially
for Fortran projects. It is covered by a BSD open-source license.
The tool is written in python, and there is an accompanying
introduction on MacResearch:
http://www.macresearch.org/tcbuild-new-build-tool-fortran
Below is a list of some of the features of TCBuild, and the ideas
behind them, taken from the article above.
Drew McCormack
TCBuild should
Not be general purpose.
It should do Fortran well, and only handle enough C to get by.
Java forget it!
Scale to millions of lines, but also be easy to use with small
programs.
Be very simple to install, preferably just one file.
Dont want to have to have a build tool to build your build tool!
Favor convention over configuration, ala Ruby on Rails and friends.
I was willing to sacrifice generality. TCBuild chooses a
reasonable convention for how projects should be laid out, and will
work in any project that is structured in that way.
Support multiple, interdependent targets.
Large projects typically have many libraries and executables.
TCBuild needs to handle dependencies between these targets.
Support multiple build configurations (eg, debug, release,
parallel, serial).
Work on all Unix/Linux platforms.
Sorry Windows users. Ive never tested TCBuild on Windows, but I
assume it doesnt work. May not take much to get it to work though.
Scale on multi-core systems.
Understand Fortran dependencies, and determine them automatically.
Not mix build configuration files (eg make files) with source files.
All configuration should be in one file in the project root. I
dont like the way make, and even scons, favor recursive builds with a
configuration file in every source directory. I dont like it for
build tools, and I dont like it for source control tools (eg. CVS and
Subversion). In my view, tools should not mix directly with the source
tree.
Have the ability to set different compile options for different
groups of files, or individual files.
Fortran compilers have bugs. It is rare that one set of compile
flags work for all files in a large program. And often you will want
to set higher optimization for certain performance critical files.
Consider the compile options used to compile a file when
determining if it needs recompiling.
This idea is stolen from SCons I find it very useful. Often you
make a change to some compiler flags for a particular subset of source
files, and then need to figure out which files need touching so that
they get recompiled. TCBuild stores the compile flags used for each
file, and knows when they have changed and the file thus needs
rebuilding.
Separate build products from source code, in a standalone directory.
Some build systems mix object files and other intermediate
products through the source tree. Not good. TCBuild puts all build
products in a standalone build directory in the project root.
Consider a file modified if its content is modified, as well as its
modification date.
Another idea taken from SCons. This can be useful if, say, you
move a file aside and temporarily replace it with some other file.
When you put it back again, most build systems will not rebuild the
file, because the modification date of the source file is not newer
than that of the object file. TCBuild will do a checksum, and see that
the file is changed.
Archives in place of object files.
Build systems like make compare the modification date of object
files to the corresponding source file to determine if a recompile is
needed. This is not very robust, and results in object files being
spread all over your project. TCBuild archives object files in static
libraries, and stores time stamps in a separate database.
---------------------------------------------------------
Drew McCormack
www.maccoremac.com
www.macanics.net
www.macresearch.org
|