scl@virginia.UUCP (09/24/87)
In article <1700@botter.cs.vu.nl> erikb@cs.vu.nl (Erik Baalbergen) writes: >The following is a request for thoughts and comments on the Unix "make" >utility. > At the Summer '87 Usenix conference in Phoenix I attended a talk by David Hume entitled "Mk: a successor to make" Hume's new "mk" (pronounced "muck") looks a lot like make and addresses quite a few of make's shortcomings. We do not have mk (I wish we did) so I am taking my info from Hume's paper in the Proceedings. As I understand it, mk will be (is ?) an AT&T toolkit product. Anyone out there know how to get it? > >1) `Make' has some shortcomings, among which the following > - there is no way to specify that a single command produces more > than one file If you have multiple targets in the same dependency rule and the rule is followed by a recipe, mk assumes that the recipe creates all the targets. > - due to the specification of explicit shell commands, Makefiles are > strongly shell and environment dependent This is also true of mk, but recipes are not one-line shell scripts executed via "sh -c". The whole recipe is executed as one shell script. > - side effects in shell commands are not taken care of; there is no > check whether a successful command results in the target to exist I don't know if mk addresses this. > - transformation (implicit) rules work under the assumption that > each kind of file has its own suffix; therefore, "make" has little > or no knowledge of the type of a file, but relies on the file naming > convention (How could you make "make" tell the difference between > a Lex source and Lisp file, which both names end in ".l") Mk doesn't restrict you to single character extensions. You can construct rules such as %.o:%.lisp ln $stem.lisp $stem.l lisp -o $stem.o $stem.l rm $stem.l $stem.lisp Note that mk puts the variable "stem" in the environment of the recipe script. Stem contains whatever the "%" matched. You can easily keep source in one directory and objects in another by having rules like %.o:../src/%.c $CC -c $CFLAGS ../src/$stem.c Mk also allows arbitrary regular expressions in metarules if the % facility isn't general enough. > - it is, e.g., hard to incorporate a "make dependencies" within a single > run of "make"; make is not able to dynamically add or change rules mk can include the standard output of a recipe as part of the "mkfile" > - time is the only file attribute that is taken into account when > comparing files; one can think of having a more general file > comparison mechanism, looking at more file attributes Mk identical to make on this point. > - it is easy to loose control when altering the Makefile, unless you > add "Makefile" to each target's dependency list; a famous example > is adding or deleting a -Dxxx flag in CFLAGS I don't think mk addresses this. >2) The "command" parts in the Makefile should be Unix-flavour (and shell) > independent and environment independent. Mk runs all recipes through sh(1). I guess that's as shell dependent as you can get. >3) The declarative "make" language should incorporate subroutines to facilitate > the description of almost identical "make" code, which otherwise occurs more > than once within a single Makefile. The user has to be able to specify > conditional and repetitive execution of commands, using only the > declarative language. > (One often sees an "if" statement programmed in a shell command.) Since whole recipes are executed as one shell script, you are free to write very long and complicated recipes using all the power of sh(1). Since mk passes all variables to recipes through the environment, the text of a recipe is copied untouched from the mkfile to the shell. >4) Parallelism, if supplied, should be transparent to the Makefile. Mk does this, but you need to specify the number of targets that can be built simultaneously (default=1). >5) Each user or group of users should have its own "make environment", > which defines system-dependent macros and actions (e.g. ".makerc", which > defines CC and specifies how to create "file.foo" out of "file.bar"); I don't think mk offers this. >6) Make should be integrated with a source-code revision-control system. > (sccs, rcs) You would have to do this yourself with metarules. Mk has many other nifty features that I won't go into. Would someone from AT&T please let us know the status of this product and how we might go about getting it? -- Steve Losen University of Virginia Academic Computing Center
henry@utzoo.UUCP (Henry Spencer) (10/19/87)
> We do not have mk (I wish we did) so I am taking my info from Hume's > paper in the Proceedings. As I understand it, mk will be (is ?) an > AT&T toolkit product. Anyone out there know how to get it? It is worth mentioning that there is a near-public-domain implementation underway. Unfortunately, as the implementor, I must add that it is also worth mentioning that I'm very busy and progress is very slow. -- "Mir" means "peace", as in | Henry Spencer @ U of Toronto Zoology "the war is over; we've won". | {allegra,ihnp4,decvax,utai}!utzoo!henry