walton@ametek.UUCP (Steve Walton) (12/17/86)
For those who neither know nor care what Make is, skip to the next
message now. This review is >60 lines long.
The Software Distillery is a group of programmers whose creations can
be found on their BBS system at 919-471-6436. They bill themselves as
"purveyors of the finest in Amiga freeware," a well-deserved label;
these are the people who brought you Amiga Hack, Amiga Kermit, BLINK,
and PopCLI. Thus, the performance of the Make utility from the SD is
all the more disappointing.
The first thing you'll do once you download MAKE.ARC from the BBS is
read MAKE.DOC, of course. It turns out to be a copy of the
documentation for the Make utility on Hewlett-Packard's UNIX System
III. It does not describe the Make program which is in the same
archive, hereafter referred to as SD Make. For example, the
documentation describes the standard UNIX convention that commands to
be executed by Make appear in the Makefile indented by a single tab.
SD Make rejects such lines as illegal, requiring a leading space
instead. There are no built-in commands in SD Make (such as how to go
from a C file to an O file); instead, such commands are supposed to
appear in the file C:BUILTINS.MAKE. I found this out the first time I
tried to run SD Make and got a "C:BUILTINS.MAKE: File not found"
error. The documentation also does not explain that SD Make requires
the : which denotes a dependency line to have white space on either
side of it; I was told this by the Sysop of the SD BBS.
I generally use Fred Fish's CC utilities which allow compiling and
linking from a single command line. CC starts the passes of the
Lattice compiler, for example, by simply doing an Execute("lc1 file.c",
0, 0). This is standard AmigaDOS usage, but when run from within SD
Make, the system crashes (both version 1.1 and 1.2). Trial and error
showed that changing the previous statement to Execute("lc1 file.c", 0,
Output()) allowed CC to work, but the two forms should be identical.
Apparently SD Make does some non-standard things when it starts up its
subsidiary commands. The next bug in SD Make appeared in the programs
handling of macros. In a large project, it is standard procedure to
define a macro such as OBJS which is a list of all your object files,
for example:
OBJS = a.o b.o
project : $(OBJS)
ln -o project $(OBJS) -lc
Thus, addition or deletion of object modules from the list need only be
done in one place. SD Make fails to handle this case properly; it
jumps to the link (the "ln" command in the example above) even if the
object files don't exist but have to be compiled from C source.
In short, SD Make is so far away from "standard" Make as to be nearly
useless. I recommend avoiding it. If you really need and want a Make
utility, you have three options: (1) Buy Lattice's LMK (Lattice MaKe
utility), but read the review in Amazing Computing Issue 8 first! (2)
Buy one of the Aztec C packages which includes their Make (version
3.40, due in January, will have Make in the $299 package). (3) Use a PD
one, of which there are several. In fact, I've just finished porting
one and will be uploading it to PeopleLink this week, certainly before
December 15.
Steve Walton
[moderator's note: this came in the next day:]
Yesterday, I posted a negative review of the Software Distillery's make
program. I had expressed similar thoughts on the SD BBS, and John
Toebes responded to the effect that I was absolutely right, that they
had gotten the program working, mostly, and were now busy with other
projects, but that if the PD Make I've ported is as good as I claim,
the SD might replace theirs with the one I've done.
In other words, this is something of a long-winded apology for
a premature and somewhat ill-conceived posting.
Stephen Walton ARPA: ametek!walton@csvax.caltech.edu
Ametek Computer Research Div. BITNET: walton@caltech
610 N. Santa Anita Ave. UUCP: ...!ucbvax!sun!megatest!ametek!walton
Arcadia, CA 91006 USA
818-445-6811
The left half of my brain disavows any knowledge of the right half.news@cit-vax.Caltech.Edu (Usenet netnews) (12/17/86)
Organization : California Institute of Technology Keywords: From: tim@tomcat.Caltech.Edu (Tim Kay) Path: tomcat!tim In article <853@ulowell.UUCP> walton@ametek.UUCP (Steve Walton) writes: >and PopCLI. Thus, the performance of the Make utility from the SD is >all the more disappointing. > >The first thing you'll do once you download MAKE.ARC from the BBS is >read MAKE.DOC, of course. It turns out to be a copy of the >documentation for the Make utility on Hewlett-Packard's UNIX System >III. It does not describe the Make program which is in the same Isn't the UNIX documentation copyrighted? Aren't you supposed to have a UNIX license before you reproduce AT&T's documents? Timothy L. Kay tim@csvax.caltech.edu Department of Computer Science Caltech, 256-80 Pasadena, CA 91125
dillon@CORY.BERKELEY.EDU (Matt Dillon) (12/18/86)
Yes, there are quite a few bugs in terms of non-implimented commands, but there are some good points too: -EXTREMELY small... 13K executable. -c:builtins.make autoinit file... this is mine: -------------------------- .c.o: lc1 -oram: -icb:include/ -icb:include/lattice/ $< lc2 -s -v -o$*.o ram:$*.q -------------------------- -Matt
phil@scubed.UUCP (Phil Cohen) (12/18/86)
It is not hard to enhance "cc" to look at the timestamps and only recompile what is needed. If you have access to the SDAUG DevDisk series, the cc distributed there has a -T option that does this.