erikb@cs.vu.nl (Erik Baalbergen) (09/23/87)
The following is a request for thoughts and comments on the Unix "make" utility. "Make" has been in use by Unix programmers for almost 10 years, and many programs and programming systems nowadays come with at least one [Mm]akefile. Many programmers have become familiar with specifying a set of rules, in order to keep their programs up to date, but as their software and the software development utilities became more complex, they had to twist and turn to let "make" know how to proceed after some change. Enhancements to `make' have been introduced to deal with the growing supply of software development and maintenance tools (e.g. sccs). Even parallel versions of "make" were developed, to make use of the large computing power of connected processors. All these augmented "make"s are based on the same declarative language introduced by S.I. Feldman's "make" in 1978. I'm interested to hear from both experienced and non-experienced "make" users how they think about the following statements. 1) `Make' has some shortcomings, among which the following - there is no way to specify that a single command produces more than one file - due to the specification of explicit shell commands, Makefiles are strongly shell and environment dependent - side effects in shell commands are not taken care of; there is no check whether a successful command results in the target to exist - 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") - 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 - 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 - 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 2) The "command" parts in the Makefile should be Unix-flavour (and shell) independent and environment independent. 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.) 4) Parallelism, if supplied, should be transparent to the Makefile. 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"); 6) Make should be integrated with a source-code revision-control system. (sccs, rcs) Apart from any comments on these statements, I would like to ask the following questions to all of you wizards. 7) Which version of "make" are you using? What are the shortcomings you observed? 8) Are there any other "things" you would like to express in "make", but which are hardly (or not) possible? Did you ever met a situation in which you were forced to use non-make constructs? (Examples are welcome!) 9) Do you have any suggestions for further enhancements, apart from the ones stated above? 10) Do you have any experience with concurrent versions of make? Please reply by email (erikb@cs.vu.nl). I'll post a summary to this newsgroup. Thanks in advance! Erik Baalbergen PS This article is not meant to be an offence against "make". I still feel that it is a great and useful tool! It's just that I'm proposing enhancements which could be incorporated in any future 'mtar."!I