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
ekrell@hector.UUCP (Eduardo Krell) (10/02/87)
In article <421@virginia.acc.virginia.edu> scl@virginia.EDU (Steve Losen) writes: (about "mk") >Would someone from AT&T please let us know the status of this product >and how we might go about getting it? You should take a look at nmake (aka newmake, aka 4th generation make), which I think is superior to mk. I already sent a note to the original poster describing nmake and how it solves almost all the complaints he had over old make. nmake is available to the outside world thru AT&T Toolchest. nmake has been described in past Usenix conferences. Some key features are: no need to specify dependencies on #include'd files. nmake does it automatically. Moreover, it will generate -I flags for cpp to look up the directories where the header files were found. You can use a .SOURCE.h : incl headers /usr/local/include and it will look for all the #include'd files in those directories (and then /usr/include, of course). nmake remembers the command line flags used to compile every file, so, for instance, if you change a -D flag or a -I flag to look for header files in a different directory, nmake will recompile. It keeps a state file with all the info on how every file was generated and the time stamp. "touch"ing a file won't fool nmake. The makefiles are compiled so that future runs of nmake won't require the Makefiles to be read and parsed again. Of course, if you've changed the Makefiles, they will be recompiled automatically. nmake has really a knowledge base on Unix (but most of it is not built into nmake, but rather put into a "Makerules" file which has all the "metarules"). For instance, If I have a library libfoo.a that contains a couple of .o's generated from their corresponding .c's and a yacc output file, all I need to specify in nmake is libfoo.a :: a.c b.c x.c gram.y (BSD) What that one line will do is compile a.c, b.c and x.c into the .o's, with a -DBSD flag depending on what BSD has been set previously in the makefile. It will run yacc on gram.y, move y.tab.c to gram.o, run ar to create the archive or update the archive and remove the .o's. There are many more features, but this gives you a feeling for what you can do. Eduardo Krell AT&T Bell Laboratories, Murray Hill {ihnp4,seismo,ucbvax}!ulysses!ekrell
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
henry@utzoo.UUCP (Henry Spencer) (10/21/87)
> You should take a look at nmake (aka newmake, aka 4th generation make), > which I think is superior to mk... It depends on what you are doing. Andrew Hume, author of mk, characterized nmake as "an expert system for C programmers". A valuable thing, yes, but less general and much more complex than mk. -- PS/2: Yesterday's hardware today. | Henry Spencer @ U of Toronto Zoology OS/2: Yesterday's software tomorrow. | {allegra,ihnp4,decvax,utai}!utzoo!henry
ekrell@hector.UUCP (Eduardo Krell) (10/21/87)
In article <8806@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >It depends on what you are doing. Andrew Hume, author of mk, characterized >nmake as "an expert system for C programmers". A valuable thing, yes, but >less general and much more complex than mk. How is nmake "less general" than mk?. Is there anything you can do in mk that you couldn't do in nmake? nmake (the program itself) is much more complex than mk because it is more powerful. However, makefiles for nmake are not complex; are much more readable and small than plain make makefiles. I'll be happy to send you examples so that you can judge for yourself. Eduardo Krell AT&T Bell Laboratories, Murray Hill {ihnp4,seismo,ucbvax}!ulysses!ekrell
henry@utzoo.UUCP (Henry Spencer) (10/30/87)
> How is nmake "less general" than mk?. Is there anything you can do in mk > that you couldn't do in nmake? I'm not familiar enough with nmake to answer in detail, but as I understand it, nmake knows a lot about C. What happens if you try to use a seriously different set of conventions for file naming etc.? Mk has no built-in knowledge to speak of, so it may need more work to customize for a particular set of needs, but it has no built-in bias. The capabilities of the two are probably equivalent in some formal sense. -- PS/2: Yesterday's hardware today. | Henry Spencer @ U of Toronto Zoology OS/2: Yesterday's software tomorrow. | {allegra,ihnp4,decvax,utai}!utzoo!henry
ekrell@hector.UUCP (Eduardo Krell) (11/01/87)
In article <8859@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >I'm not familiar enough with nmake to answer in detail, but as I understand >it, nmake knows a lot about C. What happens if you try to use a seriously >different set of conventions for file naming etc.? Actually, there are two distinct objects here: nmake itself and the nmake default rules, which are outside of nmake and are really a global makefile with all the rules about C, YACC, LEX, cc, etc. I don't believe nmake itself knows "a lot about C" more than old make does. It knows something about Unix and archives, but all the rules about generating .o files from .c or .s files, and so forth come from the nmake rules file, which can be changed by a system administrator or bypassed by the user. I am using right now 2 quite different rules files, which reflect their author's views on how to compile files. The final behavior is different, but they're both using the same nmake program. Thus, it's not nmake you're complaining about, but the default rules. Eduardo Krell AT&T Bell Laboratories, Murray Hill {ihnp4,seismo,ucbvax}!ulysses!ekrell