Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!bellcore!faline!ulysses!allegra!alice!andrew
From: andrew@alice.UUCP
Newsgroups: comp.os.misc,comp.unix.wizards
Subject: Re: Thoughts about "make" - summary
Message-ID: <7392@alice.UUCP>
Date: Wed, 21-Oct-87 23:25:25 EDT
Article-I.D.: alice.7392
Posted: Wed Oct 21 23:25:25 1987
Date-Received: Sat, 24-Oct-87 20:45:47 EDT
References: <568@erikb.cs.vu.nl> <8806@utzoo.UUCP> <3108@ulysses.homer.nj.att.com>
Organization: AT&T Bell Laboratories, Murray Hill NJ
Lines: 67
Keywords: make
Summary: an addendum by the creator of mk
Xref: mnetor comp.os.misc:310 comp.unix.wizards:5035

i was unaware of this discussion so i am responding rather tardily.
Most of the repsonses made on mk's behalf were accurate (thanks henry?).
by the way, toolchest and TOADS has mk now and educational people are being
sent tapes (mhuxd!macor for details).

1) rules producing more than one file: explicitly supported.
-) sh specific: not too much. mk doesn't care about commands because
	it doesn't look at them. the only bug is mk thinks it knows
	how the shell expands names, metacharacters etc.
-) side-effects in rule bodies: mk checks the times after the recipe
	executes so that a rule firing does not mean the target is updated.
-) suffixes are not enough: agreed. mk gives more pattern stuff than
	suffices but does not suport types for non-aggregates. It does
	try to figure out what type of thing an aaggregate is (archive etc).
-) dynamic rules: mk supports (in a clumsy way).
-) general 'depends-on' mechaism: i thought about this real hard and could not
	think of an efficent way to do this. forking a process is a loser but
	is necessary in general.
-) altering Makefile: mk manipulates files that depend on files. for subfile
	resolution (at least C-wise) use nmake.
2) recipes should be unix and shell independent: hahahaha. should they be C, or
	fortran, perhaps?
3) subroutines: i am not too sure what is meant here. mk strongly supports
	shell in recipes which gives you most of what you want. the other
	help it gives is rules for similar targets:
	(cmda|cmdb):R:	\\1.o		# R->regular expression cmda or cmdb
		$CC $CFLAGS -o $target $prereq
4) parallelism: mk runs $NPROC streams at once. the only problem is with
	braindead programs (like yacc but not lex) which produce output
	in a constant name. Even yacc can work in parallel by a (admittedly)
	more complicated rule which goes to another directory to do its work.
	what makes this work for mk is $nproc which is unique per recipe
	%.o:	%.y
		mkdir /tmp/$nproc; cp $stem.y /tmp/$nproc
		(cd /tmp/$nproc; yacc $stem.y; mv y.tab.c $stem.c)
		$CC $CFLAGS -c /tmp/$nproc/$stem.c && rm -fr /tmp/$nproc
	(i am not real proud of this but it works and doesn't need special
	mechanism inside mk).
5) customising: i am against this in principle but as mk gets its BUILTINS
	from the environment, anything is possible.
6) support for sccs/rcs: just another metarule (which is just as it should be).
7) which make do you use? mk, of course. I am scared by nmake. although
	V8 make is usable, every other make i have used is so braindead
	i can't use it anymore. Sun's make is particularly bad; however
	mk runs real fast on a sun.
8) wish-list/hard to do: mk is general enough that i personally can do all
	i want. however, chris fraser supports a compiler that involves
	five levels of directories and where programs at lower-levels
	are made, then run to make upper source files (all with one
	mkfile). processing is different on a per directory basis, too.
	his problems would be best solved by binding variables to
	upper level targets while generating the dependency graph
	for targets below. E.g.
	comp:	pdpcc vaxcc
	vaxcc:	vax/compiler   :bind 'O=vo' for lower targets
	pdpcc: pdp/compiler    :bind 'O=po' for lower targets
	%/compiler: %/*.$O	# get the right .[pv]o's
		$stem.cc -o $target $prereq

	it would also be nice to have macros in mk.
9) enhancements: extending the general depends-on relation. If you don't have mk,
	you would need to add transitive closure, real recipes (not one-liners)
	and at least, %-style metarules.
10) concurrent make: DYNIX make is an extraordinary hack; good enough
	but restricting concurrency to one line rule bodies?? come on!
PS) forgive us, stu: make is and was a fine accomplishment. however, it
	was implemented for a specific environment and purpose. time to go on.