earlw@Apple.COM (Earl Wallace) (05/03/89)
I have the AT&T Toolchest 'nmake' program, version 1.0 and was wondering if there's a poor soul out there who's found some bugs in this product and would be willing to tell me about them so I don't go crazy trying to build these new makefiles...
cgh018@tijc02.UUCP (Calvin Hayden ) (05/09/89)
> I have the AT&T Toolchest 'nmake' program, version 1.0 and was wondering if > there's a poor soul out there who's found some bugs in this product and > would be willing to tell me about them so I don't go crazy trying to > build these new makefiles... Well, here goes. First, we are using nmake now, and I have talked with Mark Forman (At&t toolchest admin) about the bugs (features :->) associated with nmake. I've been told that At&t has made major changes to nmake internally, and that they are not going to release this to Mark, despite all of his efforts -- this conversation took place around Feburary, so dont hold your breath for another update to come from the toolchest. As far as bugs... I have a list of bug fixes, but unfortunately, these were supplied by engineers using nmake, and having source to it -- I don't qualify as a C guru yet. Most of the changes to be made involved the source to cpp. One bug is that when compiling using the cpp supplied with nmake, often there are warnings about extra characters being ignored. Another I seem to remember is a problem with matching up #ifdef/#endif's - initially didn't want to do this. And another interesting one I remember is that when making a change to cpp code, and compiling again, I had to use the Sys V cpp, the nmake cpp would not work on its own output. I also remember some problem with cpp being able to 'eat its own output' - a file would be run through cpp, and the compiled, and would bomb when the compiler called cpp itself. As I said earlier, I only have an inkling of the problems seen, but I under- stand that it is being used here now. There are still some outstanding problems that have not been fixed -- makes you a bit uncomfortable when you make a kernel and get 10-15 warnings about extra characters being ignored :->. I know this isn't too specific, but hopefully, it'll let you know that you are going to encounter several problems -- mostly with cpp. I could better answer your question if I directly used nmake myself, I am but a sys admin, not a programmer/engineer. Hope it helps in any way. Calvin uucp: ...mcnc!rti!tijc03!cgh018
earlw@Apple.COM (Earl Wallace) (05/11/89)
In article <464@tijc02.UUCP> cgh018@tijc02.UUCP (Calvin Hayden) writes: >... >Well, here goes. First, we are using nmake now, and I have talked with >Mark Forman (At&t toolchest admin) about the bugs (features :->) associated >with nmake. I've been told that At&t has made major changes to nmake >internally, and that they are not going to release this to Mark, despite >all of his efforts -- this conversation took place around Feburary, so dont >hold your breath for another update to come from the toolchest. >... I have heard from several sources that nmake won't be updated via the ToolChest and this has me concerned about switching to it. I don't want to move to software that may *never* be updated. If AT&T has made major changes to nmake, uses it internally, and won't release it to the ToolChest, does this mean we'll see it in SVR5.5 as part of that release? (The theory being that if you want the improved nmake, you will have to buy 5.5) This brings up another point: With some many different 'makes' out there now (imake, gmake, nmake, etc.), is there one that really outshines the rest? nmake looks neat because you can change the global rules with ease and tailor them to your environment. Is UNIX software development goinf to rely on make programs forever? What's down the road? "Database-Driven Software Maintenance" I hope...
oz@yunexus.UUCP (Ozan Yigit) (05/12/89)
In article <1766@internal.Apple.COM> earlw@Apple.COM (Earl Wallace) writes: >This brings up another point: With some many different 'makes' out there now >(imake, gmake, nmake, etc.), is there one that really outshines the rest? In my opinion, Bell Labs MK !! It is clean (i.e. it does not have your kitchen sink in it, nor other "useful features" like built-in macro preprocessors, and other crud) and fast. Available from the the nearest toolchest. See the Summer 1987 USENIX paper for a detailed discussion. oz -- use the source, luke !! Usenet: oz@nexus.yorku.ca uh... we forgot to tell you... ......!uunet!utai!yunexus!oz it is unintelligible, but hey, you Bitnet: oz@[yulibra|yuyetti] got it, for free (!). Phonet: +1 416 736-5257x3976
andrew@alice.UUCP (Andrew Hume) (05/12/89)
at&t appears very unlikely to ever pick up mk and so i see no reason why mk updates won't continue to make their way to the Toolchest.
jhh@ihlpl.ATT.COM (Haller) (05/13/89)
In article <464@tijc02.UUCP>, cgh018@tijc02.UUCP (Calvin Hayden ) writes: [deleted] > source to cpp. One bug is that when compiling using the cpp supplied > with nmake, often there are warnings about extra characters being ignored. Recent AT&T cpp's complain about extra characters in #ifdef and #endif's. In one case I experienced, this detected a hitherto unknown bug. The cpp's are only enforcing what had alway's been a part of the 'C' language definition (see K&R pg 208). The following #ifdef/#endif usage is common, but wrong: #ifdef DEBUG /* debug code */ #endif DEBUG The proper syntax is: #ifdef DEBUG /* debug code */ #endif /* DEBUG */ The #endif control takes no arguments. Old cpp's silently ignored the debug token, but the newer ones do not. The case where I found a bug was in a section of code like this: #ifdef FEATURE1 || FEATURE2 /*common code for feature 1 and feature2*/ #endif Formerly, cpp was silently interpreting this as #ifdef FEATURE1, throwing away the "|| FEATURE2". The correct statement would have been, of course: #if FEATURE1 || FEATURE2 which is what I changed this to. Since this particular code had never been compiled without FEATURE1 but with FEATURE2, we never noticed the problem, but the new cpp picked this up right away. John Haller att!ihlpl!jhh or jhh@ihlpl.att.com
mac@mrk.ardent.com (Michael McNamara) (05/20/89)
ew> I have the AT&T Toolchest 'nmake' program, version 1.0 and was ew> wondering if there's a poor soul out there who's found some bugs ew> in this product and would be willing to tell me about them so I ew> don't go crazy trying to build these new makefiles... I would strongly suggest that you get your money back from AT&T for nmake, and get gnu-make from the Free Software Foundation. nmake is 1) quite buggy, and 2) does not use standard makefiles. gnu-make is 1) free, 2) can use standard makefiles 3) has the multiple jobs, load average sensitivity and other featues of nmake. gnu-make also has non standard makefile extentions, but you do not need to use them to get the power of parallel make, which is what I consider to be the main virtue of nmake & gnu-make. nmake pretty much requires you to re write all your makefiles (they do end up simpler) but since it requires lots of bug fixes, you end up not being able to rebuild your product because you've found another bug in nmake, and you get use /bin/make cause all your makefiles are in a different syntax. (nmake does come with buggy makefile conversion programs... deeper and deeper...) -mac (These are my opinions, formed when working for a company now out of business, so if you have a problem with these opinions, you get get in line with the creditors of that chapter 11 company...) _________________ Michael McNamara mac@ardent.com
ekrell@hector.UUCP (Eduardo Krell) (05/20/89)
In article <6561@ardent.UUCP> mac@mrk.ardent.com (Michael McNamara) writes: > I would strongly suggest that you get your money back from >AT&T for nmake, and get gnu-make from the Free Software Foundation. Why would you want to do that? nmake is much more powerful than gnu-make. > nmake is 1) quite buggy, and 2) does not use standard >makefiles. That particular version of nmake being distributed by the Toolchest might be buggy, but newer versions are not. Of course it doesn't use standard makefiles: they specify too much details. nmake makefiles are smaller by an order of magnitude. > gnu-make is 1) free, 2) can use standard makefiles 3) has the >multiple jobs, load average sensitivity and other featues of nmake. But can gnu-make prevent you from running simultaneous yacc jobs on the same directory? This wouldn't work as yacc uses a fixed file name (y.tab.c) which would be overwritten by the multiple yacc's (yes, nmake does know about yacc and other tools which can't be run in parallel). > gnu-make also has non standard makefile extentions, but you >do not need to use them to get the power of parallel make, which is >what I consider to be the main virtue of nmake & gnu-make. The parallel jobs facility is not the main virtue of nmake. The main virtue of nmake is that it uses a statefile to record what it does and it doesn't just rely on time stamps on the files to determine whether they need to be recompiled or not. This guarantees that all (and only those) files which need to be recompiled will be. Other big wins: * The implicit dependency on #include'd files (which nmake finds out on its own). * Automatic generation of -I flags for the compiler for each source file to look in the right directories where header files are. * The use of global makefiles with rules tailored to a particular environment/project. Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.com
mcgrath@paris.Berkeley.EDU (Roland McGrath) (05/20/89)
In article <11562@ulysses.homer.nj.att.com> ekrell@hector.UUCP (Eduardo Krell) writes: I will try to make my plugs as blatant and tacky as yours, but I'm not sure I can do it. (Burners off folks; I'm really a nice person. I wrote the sucker for free even.) In article <6561@ardent.UUCP> mac@mrk.ardent.com (Michael McNamara) writes: > I would strongly suggest that you get your money back from >AT&T for nmake, and get gnu-make from the Free Software Foundation. Why would you want to do that? nmake is much more powerful than gnu-make. What I know of nmake is only the things you have mentioned. But it seems to me that nmake is, in fact, LESS powerful than GNU Make. Of course it doesn't use standard makefiles: they specify too much details. nmake makefiles are smaller by an order of magnitude. GNU Make allows much smaller makefiles too, but can accept old makefiles as well. > gnu-make is 1) free, 2) can use standard makefiles 3) has the >multiple jobs, load average sensitivity and other featues of nmake. But can gnu-make prevent you from running simultaneous yacc jobs on the same directory? This wouldn't work as yacc uses a fixed file name (y.tab.c) which would be overwritten by the multiple yacc's (yes, nmake does know about yacc and other tools which can't be run in parallel). Sure. Write a rule to do it. It's not hard: %.c: %.y @while test -f $<.lock; do sleep 1; done @echo $$$$ > $<.lock $(YACC) $(YFLAGS) $< mv y.tab.c $@ @rm -f $<.lock This is rather inefficient, it's true. Version 4 of GNU Make will let you say instead: %.c: %.y .NONPARALLEL $(YACC) $(YFLAGS) $< mv y.tab.c $@ Of course, if you use Bison instead of Yacc, you can use: %.tab.c: %.y bison $< > gnu-make also has non standard makefile extentions, but you >do not need to use them to get the power of parallel make, which is >what I consider to be the main virtue of nmake & gnu-make. The parallel jobs facility is not the main virtue of nmake. The main virtue of nmake is that it uses a statefile to record what it does and it doesn't just rely on time stamps on the files to determine whether they need to be recompiled or not. This guarantees that all (and only those) files which need to be recompiled will be. This is nmake's main *selling point*. Whether such incredible hairiness is a `virtue' is highly debatable. Other big wins: * The implicit dependency on #include'd files (which nmake finds out on its own). * Automatic generation of -I flags for the compiler for each source file to look in the right directories where header files are. These, like the yacc rule, are examples of why GNU Make is, in my opinion, more powerful. It doesn't do these things for you, it's true. But it provides powerful mechanisms that let you tell it how to do them. GNU Make is very flexible; it is not limited to the applications its authors had in mind. * The use of global makefiles with rules tailored to a particular environment/project. This is not very clear, but if I understand what you're talking about, GNU Make can do that too. Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.com As stated before, GNU Make is ABSOLUTELY FREE, and is almost completely compatible with 4.3 BSD and System V `make'. AT&T itself has produced at least three (and probably more) `make' programs that are completely incompatible with one another. GNU Make is compatible with the most widely used implementations, and provides the features of AT&Ts experimental versions. -- Roland McGrath Free Software Foundation, Inc. roland@ai.mit.edu, uunet!ai.mit.edu!roland Copyright 1989 Roland McGrath, under the GNU General Public License, version 1.
mcgrath@paris.Berkeley.EDU (Roland McGrath) (05/20/89)
I should mention that the opinions expressed are mine, and do NOT represent the views of the Free Software Foundation, Richard Stallman, or anyone else except ME. Flames, if they must be directed somewhere, should be directed solely at ME, and my actions and opinions should NOT reflect on the Free Software Foundation, or anyone else. Got that? Now beat (if you must) on ME, only ME, and noone else, OK? -- Roland McGrath Free Software Foundation, Inc. roland@ai.mit.edu, uunet!ai.mit.edu!roland Copyright 1989 Roland McGrath, under the GNU General Public License, version 1.
benson@odi.com (Benson Margulies) (05/20/89)
In article <MCGRATH.89May19190412@paris.Berkeley.EDU> mcgrath@paris.Berkeley.EDU (Roland McGrath) writes: >In article <11562@ulysses.homer.nj.att.com> ekrell@hector.UUCP (Eduardo Krell) writes: Some day, Mr. Krell will realize that those of us who don't work for AT&T are only very marginally interested in the existence of wonderful software unavailable to us. We have been informed that this new version will not only not be treated as a toolchest upgrade, it won't be available at all. Perhaps AT&T is saving it up to be the only make in SysVr4, incompatibly breaking all existing makefiles? :-) If a new version is built in the middle of a forest, and no one can enter the forest to see it, is it really there? The version of nmake that exists is ridden with bugs. The code quality is so poor as to make bugfixing an endless exercise in "fix this, break that." Much of the functionality is specified in the makefile language, which is completely unstructured, has no conditional construct other than "comment out the end of the line", and inadequately documented. Just sign me, "a very unsatisfied ex-nmake customer." -- Benson I. Margulies
ekrell@hector.UUCP (Eduardo Krell) (05/21/89)
In article <MCGRATH.89May19190412@paris.Berkeley.EDU> mcgrath@paris.Berkeley.EDU (Roland McGrath) writes: >What I know of nmake is only the things you have mentioned. >But it seems to me that nmake is, in fact, LESS powerful than GNU Make. Since you haven't used nmake, shouldn't you at least read the manuals before you try to compare it to any other make? It seems fair to me. >GNU Make allows much smaller makefiles too, but can accept old makefiles as >well. OK, here's an nmake makefile for a command "foo" which is built from 2 C files (x.c and y.c) and a yacc file z.y; it also uses a library called "libfoo.a" which is built from foo1.c, foo2.c and a lex file gram.l. foo :: x.c y.c z.y -lfoo libfoo.a :: foo1.c foo2.c gram.l (nmake takes care of generating .o's from the .c's, .y's and .l's and archiving foo1.o, foo2.o and gram.o into libfoo.a. In addition, the .c files are searched for #include statement so those dependencies need not to be mentioned. Can't get any smaller than that, can it? >This is nmake's main *selling point*. Whether such incredible hairiness is >a `virtue' is highly debatable. So where you're example of why this wouldn't be a "virtue"?. Depending on just the time stamps to decide whether a file needs to be recompiled or not is simply unreliable. If you still don't see why, I can provide you with plenty of examples. >GNU Make is very flexible; it is not limited to the applications its >authors had in mind. This shows you know nothing about nmake. The features I mentioned are not part of the nmake engine but are part of the "makerules" which can be customized or changed for some other application. >This is not very clear, but if I understand what you're talking about, GNU >Make can do that too. No, it can't. Read the nmake documentation. Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.com
ekrell@hector.UUCP (Eduardo Krell) (05/21/89)
In article <362@odi.ODI.COM> benson@odi.com (Benson Margulies) writes: >We have been informed that this new version will not only not be >treated as a toolchest upgrade, it won't be available at all. This is incorrect. It will be either available through the Toolchest or as an add-on product to SVR4. > Perhaps AT&T is saving it up to be the only make in SysVr4, incompatibly >breaking all existing makefiles? :-) No. See above. Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.com
dhesi@bsu-cs.bsu.edu (Rahul Dhesi) (05/21/89)
Is it ready to compile under 4.3BSD? (The answer seems to be "no" for
a lot of AT&T software.)
--
Rahul Dhesi <dhesi@bsu-cs.bsu.edu>
UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesimcgrath@homer.Berkeley.EDU (Roland McGrath) (05/21/89)
["Bugs in the AT&T Toolchest program 'nmake'"] - ekrell@hector.UUCP (Eduardo Krell):
) In article <MCGRATH.89May19190412@paris.Berkeley.EDU> mcgrath@paris.Berkeley.EDU (Roland McGrath) writes:
)
) >What I know of nmake is only the things you have mentioned.
) >But it seems to me that nmake is, in fact, LESS powerful than GNU Make.
)
) Since you haven't used nmake, shouldn't you at least read the manuals
) before you try to compare it to any other make? It seems fair to me.
If AT&T wanted me to be able to make a fair comparison, they ought to
give me the manuals, and the product itself, to examine for free.
It seems fair to me.
) >GNU Make allows much smaller makefiles too, but can accept old makefiles as
) >well.
)
) OK, here's an nmake makefile for a command "foo" which is built from
) 2 C files (x.c and y.c) and a yacc file z.y; it also uses a library
) called "libfoo.a" which is built from foo1.c, foo2.c and a lex file gram.l.
)
) foo :: x.c y.c z.y -lfoo
)
) libfoo.a :: foo1.c foo2.c gram.l
)
) (nmake takes care of generating .o's from the .c's, .y's and .l's
) and archiving foo1.o, foo2.o and gram.o into libfoo.a. In addition,
) the .c files are searched for #include statement so those dependencies
) need not to be mentioned.
)
) Can't get any smaller than that, can it?
Not much, it's true.
To get the right results from GNU Make, however, you have to say what you
mean. foo and libfoo.a must depend on the .o files, unless the new AT&T
linker handles C, Yacc, and Lex itself.
) >This is nmake's main *selling point*. Whether such incredible hairiness is
) >a `virtue' is highly debatable.
)
) So where you're example of why this wouldn't be a "virtue"?. Depending
) on just the time stamps to decide whether a file needs to be recompiled
) or not is simply unreliable. If you still don't see why, I can provide
) you with plenty of examples.
My statement was the example. Hair, fluff, goop, etc.
) >GNU Make is very flexible; it is not limited to the applications its
) >authors had in mind.
)
) This shows you know nothing about nmake. The features I mentioned
) are not part of the nmake engine but are part of the "makerules"
) which can be customized or changed for some other application.
Then they appear to be on the same level in this regard.
) >This is not very clear, but if I understand what you're talking about, GNU
) >Make can do that too.
)
) No, it can't. Read the nmake documentation.
No, I can't. Give it to me for free and I will.
Roland McGrath
Free Software Foundation, Inc.
roland@ai.mit.edu, uunet!ai.mit.edu!roland
Copyright 1989 Roland McGrath, under the GNU General Public License, version 1.davecb@yunexus.UUCP (David Collier-Brown) (05/22/89)
In article <MCGRATH.89May19190412@paris.Berkeley.EDU> mcgrath@paris.Berkeley.EDU (Roland McGrath) writes: [commenting on state files] | This is nmake's main *selling point*. Whether such incredible hairiness is | a `virtue' is highly debatable. In article <11564@ulysses.homer.nj.att.com> ekrell@hector.UUCP (Eduardo Krell) writes: | So where you're example of why this wouldn't be a "virtue"?. Depending | on just the time stamps to decide whether a file needs to be recompiled | or not is simply unreliable. If you still don't see why, I can provide | you with plenty of examples. Not wanting to interfere unduly in a slanging match between developers (;-)), I would like to point out that neither state files maintained by programs nor dates maintained by the os are sufficient: Dates can be set inappropriately by programs modifying non-significant parts of files (ie, comments in ordinary files, other structures in compound files which are in some way "made"). State files are peculiar to the program which creates and maintains them. If that program is make, or indeed, if it is any ordinary user program, the file can only be updated by that program, and thereby can end up inconsistent with external reality. I worked on a software development environment once which kept dependency information in the main database, (ie, as a form of state file), and we found that we **had** to allow the operating system to update that information in a large number of cases, thereby adding substantial complexity to the project. --dave (dates are part of an open system, and are "Gnu"ish, states are formally more complete, and are "lab"ish. anybody got a **good* solution?) c-b
gsf@ulysses.homer.nj.att.com (Glenn Fowler[drew]) (05/22/89)
This is in response to the recent nmake chatter.
A summary of the (negative) articles on the 8/85 ToolChest nmake:
(1) it has a lot of bugs
(2) it has bad coding style
(3) it has lousy documentation
(4) it is incompatible with mymake
(5) it should be free
(6) it should compile on mynix
(7) it does too much
I'll refrain from discussing what is internally available to AT&T and
instead focus on the 8/85 ToolChest nmake.
(1) The 8/85 ToolChest nmake was developed (by me) over a 8 month period
in 1985. This was the first widely distributed version, both inside and
outside AT&T. For various reasons, all out of my control, internal fixes
and changes never made it to the ToolChest. This is unfortunate. We are
comparing a program frozen in 8/85 to a 1989 environment. I even have
trouble understanding that old code. Some of the bugs are from undetected
NULL pointer dereferences (work was mainly on a 4.2BSD vax). These bugs
were nasty as they sometimes propagated into the state file and affected
later versions that already had the bugs fixed. Other bugs came from hasty
implementation. There are many themes running through nmake (shell interface,
rule language, persistent state, makefile `compilation', dynamic dependency
generation), some more important than others. The important ones received
the most attention. As a whole, nmake was exercised more intensly than
anticipated, magnifying the weak parts of the code.
(2) This comment is closely related to (1) and was based on ``each bug fix
adds n new bugs''. nmake is a sequential machine that roams about global
declarative data structures. A local change to one part of the structure
easily affects remote parts of the code.
(3) Agreed. As I remember the documentation consisted of a README and
a man page. The man page was not an appropriate format for the entire
nmake description. However, at the time it was the best way to get the
information out.
(4) Early on I discovered that I would be spending 90% of my time avoiding
incompatibilities. The code and data would become more twisted, and, more
importantly, I would have lost interest in the whole thing. I took the
best concepts from make and dropped the arbitrary implementation details.
An observation: there are a handful of popular variants now, all compatible
with a `make' that existed 10 years ago. The only new feature that all
agree on is the pattern metarule (e.g., %.o : %.c). Using any of the
other new features is inherently incompatible.
(5) I won't even touch this one.
(6) nmake uses many os-dependent features (dup2, close fd-on exec,
signals, process group control, reading directories, etc.). These
features were detected by a monster installation script that was very
sensitive to error. This script also had to be restarted from the top.
These problems aside, such scripts are still limited to the knowledge of
the different os-dependent feature implementations. I had access to
4.2BSD vax (the home machine), system V on 3B2's and 3B20s, unixpc,
apollo, sun and handled these. Other variations were at the mercy
of the monster script.
(7) I still wrestle with this one. nmake set out with these goals:
(a) add state to increase the scope of `up to date'
(b) add constructs that avoid makefile redundancies
(c) add support for dynamic dependency generation (e.g., #include's)
(d) support concurrent action execution
(e) do all of this efficiently
Early implementations tackled these brute force. Some of the details
were too visible. Later versions do a better job of layering. Most
of the complaints about ``too many *nix assumptions'' and ``do it
nmake's way or else'' are actually in the realm of the global rules
rather than in the guts of the C code. Granted, the global rules
were hairy, but they can and have been changed.
I'll be glad to discuss the current nmake off-line and summarize to the net.
--
Glenn Fowler (201)-582-2195 AT&T Bell Laboratories, Murray Hill, NJ
uucp: {att,decvax,ucbvax}!ulysses!gsf internet: gsf@ulysses.att.comdbk@mimsy.UUCP (Dan Kozak) (05/23/89)
In article <1981@yunexus.UUCP> davecb@yunexus.UUCP (David Collier-Brown) writes: > --dave (dates are part of an open system, and are "Gnu"ish, > states are formally more complete, and are "lab"ish. > anybody got a **good* solution?) c-b This may only show my naivete, but has anyone implemented a make that uses the actual contents (i.e. a CRC or other checkvalue) to compute whether something should be re-made? In fact, you could first send the file thru one of the many "de-commenting" programs that were floating around comp.lang.c a few months ago, if you didn't want a file recompiled when you just changed the comments. (and some people thought those programs were useless :-) #dan dbk@mimsy.umd.edu uunet!mimsy!dbk
jw@pan.UUCP (Jamie Watson) (05/23/89)
In article <11562@ulysses.homer.nj.att.com> ekrell@hector.UUCP (Eduardo Krell) writes: >In article <6561@ardent.UUCP> mac@mrk.ardent.com (Michael McNamara) writes: >> nmake is 1) quite buggy >That particular version of nmake being distributed by the Toolchest >might be buggy, but newer versions are not. Exactly what does this mean? Are the "newer versions" being sold through the toolchest? The last time I heard anything about this someone posted a note saying that AT&T had basically abandoned any thoughts of updating nmake in the toolchest. jw
friedl@vsi.COM (Stephen J. Friedl) (05/23/89)
In article <7346@bsu-cs.bsu.edu>, dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes: > Is it ready to compile under 4.3BSD? (The answer seems to be "no" for > a lot of AT&T software.) Hold it folks. Remember that the Toolchest is a box of UNSUPPORTED software. This means that you are on your own if you want to buy it, and it is NEVER advertised as "production" code. Many seem to think the choice is: as-is code -vs- commercially-supported code This is not the case, as the commercially-supported code is available via the normal product channels. With the Toolchest, your choice is: as-is code -vs- not available at all If you are building a project, want a commercially-supported make-like tool available everywhere, DON'T BUY NMAKE, ok? Many of us believe that nmake will be a supported tool from AT&T in Sys V Release 4.0. Steve -- Stephen J. Friedl / V-Systems, Inc. / Santa Ana, CA / +1 714 545 6442 3B2-kind-of-guy / friedl@vsi.com / {attmail, uunet, etc}!vsi!friedl "Embrace your dealer: hugs *and* drugs" - me
mac@mrk.ardent.com (Michael McNamara) (05/24/89)
In article <11562@ulysses.homer.nj.att.com> ekrell@hector.UUCP (Eduardo Krell) writes: |In article <6561@ardent.UUCP> mac@mrk.ardent.com (Michael McNamara) writes: | |> I would strongly suggest that you get your money back from |>AT&T for nmake, and get gnu-make from the Free Software Foundation. | |Why would you want to do that? nmake is much more powerful than |gnu-make. | |> nmake is 1) quite buggy, and 2) does not use standard |>makefiles. | |That particular version of nmake being distributed by the Toolchest |might be buggy, but newer versions are not. | Where would you get these? how much *MORE* would they cost? What address might you report bugs to? |Of course it doesn't use standard makefiles: they specify too much |details. nmake makefiles are smaller by an order of magnitude. | Gnu-make also supports much smaller makefiles, by providing a richer set of builtin rules. Gnu-make also supplies builtin rules for documentation tools, an important part of any project development. Gnu-make further supports gnu-emacs generic development environment, giving error messages which are complete (with directory) to facilitate emacs's next-error function. All these new features leverage off the thousands of human hours which have gone into creating Make trees. Nmake tells you to throw all those away and use the new system. In processor design a rule of thumb is that if you do not provide 4x performance increase, you must provide backwards compatibility. Users will not 'make' so extensive a switch unless it gives them large rewards. What Nmake provides is not enough for me to convince my company to switch. ( My last company switched to nmake, and they're OUT OF BUISINESS :-) :-) :-) Cydrome... Another new technology that wasn't 4x the standard offering... [I couldn't resist... The implication that nmake had anything to do with cydrome's demise is greatly exagerated and heavily :-)'ed ] |> gnu-make is 1) free, 2) can use standard makefiles 3) has the |>multiple jobs, load average sensitivity and other featues of nmake. | |But can gnu-make prevent you from running simultaneous yacc jobs |on the same directory? This wouldn't work as yacc uses a fixed file bison, gnu's replacement for yacc, is upwardly compatible with standard yacc syntax, with the addition of the feature that file.y produces file.c by default (there is a switch to revert to yacc's fixed file name). bison also has a hairy mode (called bison.hairy..) that supports error recovery and limited look ahead. |name (y.tab.c) which would be overwritten by the multiple yacc's |(yes, nmake does know about yacc and other tools which can't be run |in parallel). Further, these `other tools' following yacc's baroque (sp?) behavior could have explicit dependcies described in the Makefile, in a manner that any make program could understand. | |> gnu-make also has non standard makefile extentions, but you |>do not need to use them to get the power of parallel make, which is |>what I consider to be the main virtue of nmake & gnu-make. | |The parallel jobs facility is not the main virtue of nmake. The main |virtue of nmake is that it uses a statefile to record what it does |and it doesn't just rely on time stamps on the files to determine |whether they need to be recompiled or not. This guarantees that |all (and only those) files which need to be recompiled will be. | This is nice, and is a definate step forward in make technology. Although I will note that it many times got in my way. I find myself, when using regular make, doing things like: "touch `grep -l MAXSIZE *.c`; make" when I change the definition of MAXSIZE in some header file. nmake (perhaps quite correctly) would not let me get away with those shenaigans. (It would insist on compiling every file that included the .h file that I changed...) Nmake does have a -A switch, which causes it to ignore it's statefile; I used this to effect my touch trick above. |Other big wins: | |* The implicit dependency on #include'd files (which nmake finds | out on its own). | See above... further, gnu-make supports included makefiles, enabling make-depend and cc -M to work. |* Automatic generation of -I flags for the compiler for each source | file to look in the right directories where header files are. | I'm not sure what you mean by this... With every cpp I am aware of, if the .c file says #include "/usr/foo/dz.h" you don't need a -I; if it says <sys/reg.h> you don't need a -I; if it says "limit.h" you don't need a -I. The only time you need a -I is when you want it to get <sys/reg.h> from /cross/I860/sys/reg.h, or some such, and how can nmake know that? If you say from the environment, most makes let you do this; If you say from a base project makefile, sysV, sun and gnu-make let you do this. I am perplexed by what you mean. |* The use of global makefiles with rules tailored to a particular | environment/project. | Many makes allow superior makes to pass environments to children makes; what nmake does can be done this way (although, perhaps not as cleanly). |Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ | |UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.com So in conclusion, gnu-make offers the parallel make feature, but not the Makefile.s state file of nmake. gnu-make is free, has a mailing list for bug reports/fixes, and is distributed widely. Further, you can use gnu-make as a replacement for /bin/make, add a MAKEFLAGS=-j3 to your environment, and recompile your entire source tree, without changing all you makefiles. (it would help if you had a multiprocessor machine. (gnu-make does support remote compilation, so you guys with 20 3/50's with a common nfs mounted directory can exploit your available parallelism)) Further, if you stumble upon a gnumake bug, you can still ship your code using /bin/make. Nmake has a complicated additional feature, and costs $$. _________________ Michael McNamara mac@ardent.com
ekrell@hector.UUCP (Eduardo Krell) (05/25/89)
In article <6639@ardent.UUCP> mac@mrk.ardent.com (Michael McNamara) writes: > See above... further, gnu-make supports included makefiles, enabling >make-depend and cc -M to work. but this is something that should be automatic. I shouldn't have to type any additional commands in order for implicit dependencies to work. >The only time you need a -I is when you want it to get <sys/reg.h> >from /cross/I860/sys/reg.h, or some such, and how can nmake know that? With a line like: .SOURCE.h : /cross/I860 > Many makes allow superior makes to pass environments to children makes; >what nmake does can be done this way (although, perhaps not as cleanly). No, there are things you can't do by setting environment variables (like changing the metarules, adding new default rules, etc.) >Nmake has a complicated additional feature, and costs $$. These "complicated additional features" are needed in the real world where vanilla make (and gnu-make) are just not powerful enough. Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.com
rsalz@bbn.com (Rich Salz) (05/25/89)
In <1122@vsi.COM> friedl@vsi.COM (Stephen J. Friedl) writes:
=Many seem to think the choice is:
= as-is code -vs- commercially-supported code
=This is not the case ...
= your choice is:
= as-is code -vs- not available at all
=Many of us believe that nmake will be a supported tool from AT&T in
=Sys V Release 4.0.
So the choice is "pay a little bit of money to alpha-test now something
that will be available later"?
People's gripes seem to be the following:
If I buy a car and it turns out to be a lemon, I can return it; here I
can't
It's not as solid as people have been led to believe (for whatever reason)
Better versions are available, but (unlike ksh) you can't get them
from the toolchest, and you may not even be able to get them at all
/r$
--
Please send comp.sources.unix-related mail to rsalz@uunet.uu.net.andrew@alice.UUCP (Andrew Hume) (05/25/89)
In article <17678@mimsy.UUCP>, dbk@mimsy.UUCP (Dan Kozak) writes: > This may only show my naivete, but has anyone implemented a make that > uses the actual contents (i.e. a CRC or other checkvalue) to compute > whether something should be re-made? In fact, you could first send > the file thru one of the many "de-commenting" programs that were > floating around comp.lang.c a few months ago, if you didn't want a > file recompiled when you just changed the comments. (and some people > thought those programs were useless :-) mk can support this (but it costs you cycles). the syntax is (mk sticks per rule attributes between double colons) goo:Pcmp: foo put your commands here the semantics are that when mk wants to know if goo is out of date w.r.t. foo, it sh -c's whatever string comes after P and terminated by the traling :. a non-zero exit status means it is out-of-date. so in the above example, goo is up to date if it is the same as foo, independent of any datestamps.
snoopy@sopwith.UUCP (Snoopy) (05/30/89)
In article <11562@ulysses.homer.nj.att.com> ekrell@hector.UUCP (Eduardo Krell) writes: | That particular version of nmake being distributed by the Toolchest | might be buggy, but newer versions are not. If it is not available to persons outside of AT&T, then it might as well not exist at all, as far as they are concerned. | But can gnu-make prevent you from running simultaneous yacc jobs | on the same directory? This wouldn't work as yacc uses a fixed file | name (y.tab.c) which would be overwritten by the multiple yacc's | (yes, nmake does know about yacc and other tools which can't be run | in parallel). Sounds like a bug in yacc to me. Why not fix yacc to use a unique filename? _____ .-----. /_____\ Snoopy ./ RIP \. /_______\ qiclab!sopwith!snoopy | | |___| parsely!sopwith!snoopy | tekecs | |___| sun!nosun!illian!sopwith!snoopy |_________|