bernhold@qtp.ufl.edu (David E. Bernholdt) (05/31/90)
A couple weeks ago, I posted a query about what kinds of tricks people use in maintaining large Fortran program using 'make'. I didn't get too many responses, and most of those suggested specific versions of make to use. There were several votes for 'nmake' from the AT&T Toolchest, a vote for GNU-make, from you local GNU archive site, and one for Nelson Beebe's make, based on the PD make posted to net.sources in 1986, which works on TOPS-20, VMS, MS-DOS, UNIX, EON, and OS/9 operating systems. This can be obtained from ctrsci.math.utah.edu:lib1:[tex.pub.make] (VMS directory syntax). There was also a vote for Sun make, which is, of course, unique to Suns (although the features can often be found elsewhere). One of the things I had hoped to avoid was having to port/install yet another support tool (i.e. make) at every site we use -- for us perhaps a dozen different sites at any moment. The features of these "enhanced" makes are very nice, however. Its a hard choice whether to depend on them or not. On to other suggestions -- the "tricks"... Include files can be handled with a script to run sed, which can be made independent of the compiler's syntax for including. CPP, or whatever preprocessor can be run to produce "distribution" files to be sent to sites without the preprocessor. With a little cleverness, a single makefile can be used to either preprocess & compile the routines locally or prepare a "source distribution". There are several ways to fake conditional macro definitions. Some makes allow recursive macro evaluation -- thinks like 'FFLAGS = $(FFLAGS-$(ARCH))' where you define FFLAGS-cray and FFLAGS-sun and whatever else beforehand. The you specify ARCH=cray on the command line to get the FFLAGS you want. Most makes, hoever, can't even do this. My solution here is to run a sed script over a "master" makefile to produce a "local" makefile which has the "-$(ARCH)" substituted to be "-cray" throughout, then use that makefile for a subsidiary make. With a macro like WHERE, with values of 'l' for local or 'x' for export, you can make suffix rules that will process differently for local compilation or source distributions -- the spawned shell can test $(WHERE) however it likes. Another way to handle this might be to have two sets of suffix rules -- one for local & one to make source distributions, and just put them as part of a series of -f arguments to a subsidiary make, since make effectively cats all of the given makefiles together & acts on the overall result. If you are willing to maintain separate files of macro definitions for every architecture you use, this could also be a way of faking conditional macros. For us, however, that leads to too many files to manage! To simplify building programs for different architectures in the same directories, I setup a directory for each architecture parallel to the root of the program's source tree. These directories hold all objects, libraries, and executables. Suffix rules should insure that objects are not left lying around in the source tree, where they are originally built. Anything which requires a lot of architecture-dependent processing can be collected into special direcories in the source tree and provided with the necessary specialize makefiles. Thanks to all who responded with ideas & suggestions. -- David Bernholdt bernhold@qtp.ufl.edu Quantum Theory Project bernhold@ufpine.bitnet University of Florida Gainesville, FL 32611 904/392 6365