Wednesday, 3 February 2010

Nag uses a build system based on make and makefiles.
When we started doing things this way not enough years ago, we read and took the advice in Peter Miller's Recursive Make Considered Harmful to heart. As a result you can end up with a huge monolithic
makefile.
You can of course break this down a bit by using include makefiles, so you could, potentially, have a tree of makefiles included inside one another. We don't do much of that; we do the important thing of separating all the implementation specific stuff into a single include file which then defines the build, but the rest is still pretty monolithic. There are obvious disadvantages in maintaining such a beast, but there are advantages too:

global search and replace;

don't have to find out which makefile does what.

I'm aware that make is a fairly old technology now, although we did standardise on GNUmake which added quite a number of useful features over the years. However, I don' think it handles things like Fortran module dependencies very well, so I occassionally go on the look out for make replacements. In recent times I had a look at cons and scons as possible replacements, but was made nervous by certain things:

converting our very large makefiles would take some effort;

some reports that scons runs very slow for big builds;

having to build up an expertise in scons among our developers replacing existing expertise with makefiles.

I've got as feeling though that life with make is going to get more painful as time goes on.

In-house NAG has a set of f95 tools using our compiler technology. This includes nag_depend95 "analyses the source files to produce a list of the compilation dependencies on modules and include files. This list is in the format required by make."

Where C and Fortran are mixed together we have to rely on scripting around nm to get the full call tree from (say) an example program.

I didn't have to do very much to get SCons working, and this wasn't a big build so I can't comment on its performance (if you want an example of a larger project, I see that SCons is used in the build of the Chromium browser).

Thanks Jeremy, I'll have a look at the VR Juggler report. Interesting info also on Chromium using SCons.I'll try a mini-project using SCons to get a better idea of its ease of use and potential pitfalls.

Contributors

About NAG

The Numerical Algorithms Group (NAG) is dedicated to applying its unique expertise in numerical engineering to delivering high-quality computational software and high performance computing services. For 40 years NAG experts have worked closely with world-leading researchers in academia and industry to create powerful, reliable and flexible software which today is relied on by tens of thousands of individual users, as well as numerous independent software vendors. NAG serves its customers from offices in Oxford, Manchester, Chicago, Tokyo and Taipei, through local staff in France and Germany, as well as via a global network of distributors.