Make considered painful

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.


  1. Yes, getting F90 modules correct in a makefile seems non-trivial and compiler-dependent unless you make both .o and .mod dependencies

    My biggest chore is determining dependencies (eg which .f90 require which module file) - anybody know tools to ease this pain?


  2. 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.

  3. I used SCons in the large-scale visualization of heart data, because it was part of the required software stack for the build of VR Juggler, a toolkit which can help port OpenGL applications to a virtual reality environment. Some technical details are given in this report.

    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).

  4. 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.


Post a Comment

NAG moderates all replies and reserves the right to not publish posts that are deemed inappropriate.

Popular posts from this blog

Implied Volatility using Python's Pandas Library

C++ wrappers for the NAG C Library

ParaView, VTK files and endianness