bernhold@qtp.ufl.edu (David E. Bernholdt) (08/11/89)
I guess the subject says most of it. Do people use the generic unix make utility to build programs? What alternatives are available/in use? I've read about cake -- I'm sure there must be others. My situation is probably not unique: My group maintains a research code of > 300,000 lines. It presently runs on many different hardware/OS combinations, as many non-unix as unix. The "master" source is kept on a single machine and "remote" machines have pre-processed copies of the source which are compilable on that hardware/OS. As you might imagine, making sure all of the changes a propagated to all machines properly can be a real nightmare. I am trying to develop a set of makefiles which are general (I don't want to spend my life tailoring makefiles for every program tha comes along) and have the ability to 1) generate an executable from either un- or pre-processed source (for unix-based machines) NOTE: In some cases, this will involve making a number of different executables even from a single pre-processed source. For example, a Sun network where you need SPARC, Sun3-FPA and Sun3-68881 executables. 2) generate a source "update" for non-unix machines (and probably a script for the OS which will build the new/changed pieces and make a new executable to go with it) The code is mainly fortran, but I would like the makefiles to be able to handle C, shell, etc. as well. A colleague (sp?) of mine developed a pretty general set of makefiles and a "generator" for them. It satisfies (1) pretty well, but is inadequate for (2), and does not readily admit of other languages. He and I are working on an improved version, and the more I try to make a clean, general makefile, the more frustrated I get. Our initial decision was that we should stay with the generic make because that means one less "support tool" to port to each machine we want to run on. It is fairly important to us that a new installation of our code not require too much baggage, but I am becoming ever more strongly convinced that make is not the right tool for the job. What I know about cake, for example, tells me that it would handle this *much* better. I am interested in your own experiences -- with projects of this "scope" (its not the size of the code, but that we have to run it wherever we can get time) and with make and make replacements. Thanks... -- David Bernholdt bernhold@qtp.ufl.edu Quantum Theory Project bernhold@ufpine.bitnet University of Florida Gainesville, FL 32611 904/392 6365
jbeard@quintus.UUCP (Jeff Beard) (08/12/89)
Instead of porting make and the requisite makefile to each Target system, have the master makefile generate "command steams". The single source control is a requirement, but you've already got that defined. The scenario goes like this, master source file modifiaction(s). make -n Target_name >Target.cmd_stream upload Target.cmd_stream to Target system execute cmd_stream Don't try to emit the precise command sequence per se. JCL or CLIST streams for MVS are a B*T*H. Even VM/370 EXECs or VMS scripts can be too. Instead, define a macro/meta approach that allows the target system total freedom of implementation, eg: 'devupd proc source_name_1' for each file to be processed. devupd is a master procedure to process arguments and create a job/command sequence intended. arg proc is a generic label for 'what to perform', compile, load, update,... arg source_name_1 is the file to be processed by 'proc'.
andrew@alice.UUCP (Andrew Hume) (08/13/89)
i am the author of mk, one of the many variants on make. mk (source) is available from the at&t toolchest for a small fee. there is a paper on mk in the 1987 summer usenix (phoenix) proceedings, or you can mail me to send you a copy. for all that, mk is still much the same as make. it has several improvements: much faster, recipes are pure shell scripts, transitive closure on metarules (it can figure out to use %.a:%.b and %.b:%.c to derive a %.a from a %.c) and numerous other goodies. andrew hume andrew@research.att.com research!andrew