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: /p>
- 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.