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.
		• Don’t 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. I’ve never tested TCBuild on Windows, but I  
assume it doesn’t 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  
don’t like the way make, and even scons, favor recursive builds with a  
configuration file in every source directory. I don’t like it for  
build tools, and I don’t 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