Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!cica!iuvax!rutgers!att!cbnewsc!gregg
From: gregg@cbnewsc.ATT.COM (gregg.g.wonderly)
Newsgroups: comp.sys.amiga
Subject: Re: Lattice/Manx Makefiles
Message-ID: <12387@cbnewsc.ATT.COM>
Date: 21 Dec 89 21:19:33 GMT
References: <129401@sun.Eng.Sun.COM>
Organization: AT&T Bell Laboratories
Lines: 44

From article <129401@sun.Eng.Sun.COM>, by drh@sun.Eng.Sun.COM (D. Ryan Hawley):
> Any help I can get regarding converting
> makefiles from MANX to Lattice would be much appreciated!

I was really impressed with the Lattice stuff when I got it.  But after I
had a chance to inspect things more closely I discovered that there were
several things that were done "plain wrong".  For instance, they include
a program called grep, but whose arguments and default behavior
(and for no apparent reason) are different from the UN*X grep.  Either it
is grep or it is not.  If it is not a proper subset of grep, then it should
not be called grep.

LMK has many non-make like behaviors.  One of the most rediculous is that
if you list a dependency as 

file.c: file1.h file2.h file3.h

It will ALWAYS compile file.o because file.c and file.h are always out
of date.  Normal make does not have this behavior, it checks starting out
the highest level of generation and stops when it finds that the .o is
newer than the dependents of file.c.  Normally, I don't use this type
of dependency, but sometimes file.c comes from something non-standard
to makes builtin knowledge.

I don't use LMK, I use a version of MAKE that I got off of the Lattice
Bulletin board, it works much better (I believe that it was with a whole
bunch of other UN*X tools that I use too).

Another gripe I have with the Lattice stuff is sscanf().  I have had
to recode two applications that used it because it just plain didn't
work.  Why Lattice can't buy the rights to proven libraries instead of
giving us this broken stuff is beyond me!  As I have said before,
"Libraries limit bugs to very local areas, so why reinvent the code in
them, when the code there is known to work?"

The UN*X scanf/make/grep really do work, why can't we have them?

You bet I am frustrated.  I have been hit with too many brick walls while
trying to port straight forward C programs.  And all because of broken
libraries and brain-damaged tools.

-- 
-----
gregg.g.wonderly@att.com   (AT&T bell laboratories)