greyham@hades.ausonics.oz.au (Greyham Stoney) (10/03/90)
My company is working on a medium-to-large software project for which we use standard System-V 'make' to specify the rules by which objects are made from source files, and for specifying the source file dependancies. There are some problems with this however, which lead me to ask if there is anything better we could use; In particular, 'make' seems to have the following annoying problems & deficencies: * The Makefile is assumed to reside in the current directory and each Makefile must contain the rules saying how to make objects, since make's built-in rules aren't right. We have well over 100 Makefiles in one project; most of which contain basically the same information; but with minor differences. Eg: they all contain the same command to put an object in a library, although the library name differs. Changing the name of the librarian utility (if we needed to) would be impossible (have to change 100+ Makefiles just to do that). * Dependancies must be explicitly listed in the Makefile; and they are never kept up to date: No ammount of forcing people is going to keep them up to date, and it's a pretty pointless exercise anyway. In order to control the rules with which our objects are made, we delta Makefiles which makes it even worse since to update the depenancies you have to get the thing for editing. Why can't the dependancies be discerned from the source file at make time?. Are there any make-like systems that conquer these two basic problems?. Greyham. -- /* Greyham Stoney: Australia: (02) 428 6476 * greyham@hades.ausonics.oz.au - Ausonics Pty Ltd, Lane Cove, Sydney, Oz. * Neurone Server: Brain Cell not Responding. */
flint@gistdev.gist.com (Flint Pellett) (10/03/90)
greyham@hades.ausonics.oz.au (Greyham Stoney) writes: >My company is working on a medium-to-large software project for which we use >standard System-V 'make' to specify the rules by which objects are made from >source files, and for specifying the source file dependancies. >There are some problems with this however, which lead me to ask if there is >anything better we could use; In particular, 'make' seems to have the following >annoying problems & deficencies: >* The Makefile is assumed to reside in the current directory and each Makefile > must contain the rules saying how to make objects, since make's > built-in rules aren't right. We have well over 100 Makefiles in > one project; most of which contain basically the same information; but > with minor differences. Eg: they all contain the same command to put > an object in a library, although the library name differs. Changing the > name of the librarian utility (if we needed to) would be impossible > (have to change 100+ Makefiles just to do that). You can "include" other files into your makefile to handle this: just put all the stuff that every makefile uses into a makefile.h someplace, and then add this line into all the makefiles: include /wherever/makefile.h (Note: it is not a #include, as that would be a comment.) Appropriate use of environment variables in the .h file, (like to contain the library name in your example) should allow your one .h file to handle a lot of the overhead in the other makefiles. Deciding what to put in this .h is something you need to think over carefully though. >* Dependancies must be explicitly listed in the Makefile; and they are never > kept up to date: No ammount of forcing people is going to keep them up > to date, and it's a pretty pointless exercise anyway. In order to > control the rules with which our objects are made, we delta Makefiles > which makes it even worse since to update the depenancies you have to > get the thing for editing. Why can't the dependancies be discerned > from the source file at make time?. I've always though that at least something of this level should be possible. At the very least, figuring out what .h files a file depends upon, by scanning it for #include commands, could be done at make time. But you wouldn't want make to always do that, because it would slow down the process too much. (Maybe an option to test dependancies, and then optionally add them into the makefile when it finds missing ones, would be a good addition.) Unfortunately, I don't know of anything that does this right now- the closest things are things that will create a makefile for you by figuring out the dependancies, and those are pretty much worthless when you already have a complex makefile existing. -- Flint Pellett, Global Information Systems Technology, Inc. 1800 Woodfield Drive, Savoy, IL 61874 (217) 352-1165 uunet!gistdev!flint or flint@gistdev.gist.com
blm@6sceng.UUCP (Brian Matthews) (10/04/90)
In article <1990Oct3.000440.5275@hades.ausonics.oz.au> greyham@hades.ausonics.oz.au (Greyham Stoney) writes: |* The Makefile is assumed to reside in the current directory and each Makefile |must contain the rules saying how to make objects, since make's |built-in rules aren't right. You don't mention what version of System V you're running, but I believe make from Version 2 on up has understood the include statement. I can't recall the exact syntax, but at my last job we had a file containing all of the special rules we needed, then each makefile just included it. For things that couldn't be handled by inference rules, we came up with a set of variables that were set in the include file and used by all of the makefiles. This worked pretty well, and allowed changes to be made in one place. It also allowed our integration group to have a different included file that did things they needed to do, but to use everyone's makefiles unchanged. |* Dependancies must be explicitly listed in the Makefile; and they are never |kept up to date: No ammount of forcing people is going to keep them up |to date, and it's a pretty pointless exercise anyway. [...] |Why can't the dependancies be discerned from the source file at |make time?. You can do this with make as well. There are a number of ways, but you basically want the makefile to depend on all of the sources. If a source file changes, run a program that extracts include dependencies and builds a new makefile. |Are there any make-like systems that conquer these two basic problems?. Both can be handled fairly easily by make already. -- Brian L. Matthews blm@6sceng.UUCP
davidm@uunet.UU.NET (David S. Masterson) (10/04/90)
In article <1990Oct3.000440.5275@hades.ausonics.oz.au> greyham@hades.ausonics.oz.au (Greyham Stoney) writes: My company is working on a medium-to-large software project for which we use standard System-V 'make' to specify the rules by which objects are made from source files, and for specifying the source file dependancies. There are some problems with this however, which lead me to ask if there is anything better we could use; In particular, 'make' seems to have the following annoying problems & deficencies: * The Makefile is assumed to reside in the current directory and each Makefile must contain the rules saying how to make objects, since make's built-in rules aren't right. We have well over 100 Makefiles in one project; most of which contain basically the same information; but with minor differences. Eg: they all contain the same command to put an object in a library, although the library name differs. Changing the name of the librarian utility (if we needed to) would be impossible (have to change 100+ Makefiles just to do that). A couple of things in the standard MAKE can help this situation: 1. You can redefine the standard built-in rules to anything you want by redefining the SUFFIXES list and creating new suffix rules (of the form '.suf1.suf2:'). These 'new' standard rules could then be put into a Makefile include file and use M4(1) to build the Makefile at run-time from the Makefile.m4 file and the include file. One of the standard rules that you would add, for instance, is the rule to make a Makefile from a Makefile.m4. 2. Good use of MACROS can make the Makefile extremely flexible. For instance, "LIBUTIL=ar" and "LIBUTILFLAGS=rv" could be defined to make your standard library utility AR(1), but these macros could be redefined at anytime on the MAKE command line, if you need to change your library utility on a temporary basis. If you need to make it permanent, then these MACROS could also be put in the include file (see 1) so that you would only make the change in one place. * Dependancies must be explicitly listed in the Makefile; and they are never kept up to date: No ammount of forcing people is going to keep them up to date, and it's a pretty pointless exercise anyway. In order to control the rules with which our objects are made, we delta Makefiles which makes it even worse since to update the depenancies you have to get the thing for editing. Why can't the dependancies be discerned from the source file at make time?. The Sun extensions to the standard MAKE for SVR4 will actually do this (when set up properly). There was a "depends" program floating around somewhere (probably Berkeley) that could read C programs and determine its dependencies in a form that could be put into the Makefile. I forget how it worked exactly, but it was mostly a shell script using GREP and AWK to find "#include" statements. These were then massaged into a Makefile form which was then con'CAT'ted onto the end of the Makefile. This was a standard rule that was executed first thing via a "make depend" command (it shouldn't need to be run that often -- how often do you add a new dependency to a file?). If you can't find "depends", it shouldn't be that hard to make yourself (its not terribly complex). BTW, with this approach, you only delta the Makefile.m4 file (which doesn't have dependency lists). Are there any make-like systems that conquer these two basic problems?. Does this help? -- ==================================================================== David Masterson Consilium, Inc. uunet!cimshop!davidm Mtn. View, CA 94043 ==================================================================== "If someone thinks they know what I said, then I didn't say it!"
rick@tetrauk.UUCP (Rick Jones) (10/04/90)
In article <1990Oct3.000440.5275@hades.ausonics.oz.au> greyham@hades.ausonics.oz.au (Greyham Stoney) writes: >My company is working on a medium-to-large software project for which we use >standard System-V 'make' to specify the rules by which objects are made from >source files, and for specifying the source file dependancies. I built a specialised development environment for my company's own products, which used standard "make", but relied on driving it from a shell script. Since "make" imports environment variables into its parameter set, the script can use shell logic to assign appropriate values to environment variables, so that one standard makefile can serve everyone. I.e. the script invokes "make" in the form "make -f $TOOLS/make.master" where TOOLS contains the path of the appropriate directory. The make.master file of course defines almost everything in terms of variable parameters. In my case this was further enhanced by the main "make" calling a secondary "make" using a local makefile, and the local makefile was constructed automatically by a makefile generator program! This was solely to cater for the problem of building libraries, which is a real kludge in "make". This allowed the programmer to define his library members in a simple ASCII text file, rather than have to get makefile syntax right. I didn't do include-file dependency analysis because we didn't really need it, but you could use this approach. The makefile generator takes a while to get right, but the first step above of combining shell and make is not too hard, and considerably augments the effective power of "make" with relatively little effort. -- Rick Jones The definition of atomic: Tetra Ltd. from the Greek meaning "indivisible" Maidenhead, Berks, UK So what is: rick@tetrauk.uucp an atomic explosion?
tomr@ashtate (Tom Rombouts) (10/05/90)
>In article <1990Oct3.000440.5275@hades.ausonics.oz.au> greyham@hades.ausonics.oz.au (Greyham Stoney) writes: > |* Dependancies must be explicitly listed in the Makefile; and they are never |kept up to date: No ammount of forcing people is going to keep them up |to date, and it's a pretty pointless exercise anyway. [...] |Why can't the dependancies be discerned from the source file at |make time?. Just for information, Zortech's C++ compiler includes a MAKEDEP utility that "...will automatically produce dependency lists for you." You essentially include a list of source files and then direct the output to a file "...which can then be used as the basis for a makefile." I have not used this, however, but I would also suspect that similar tools must exist for the *nix world. Tom Rombouts Torrance Techie tomr@ashtate.A-T.com V:(213) 538-7108
alan@cwi.UUCP (Alan Wright ) (10/06/90)
In article <1015@gistdev.gist.com>, flint@gistdev.gist.com (Flint Pellett) writes: > greyham@hades.ausonics.oz.au (Greyham Stoney) writes: > > >My company is working on a medium-to-large software project for which we use > >standard System-V 'make' to specify the rules by which objects are made from > >source files, and for specifying the source file dependancies. > > >There are some problems with this however, which lead me to ask if there is > >anything better we could use; YES! You might wish to check into our product, Amplify Control(TM) from Caseware. It is specifically designed to provide a highly general and flexible build capability which exceeds the capabilities of make (and variants). All of the problems mentioned in these articles have straightforward solutions under Amplify. (Incidentally, the build procedure is specified both algorithmically and by graphical description of the data flow involved.) I should also mention that Amplify incorporates advanced configuration management features, and thus may replace both make and SCCS. > >* Dependancies must be explicitly listed in the Makefile; and they are never > > kept up to date: No ammount of forcing people is going to keep them up > > to date, and it's a pretty pointless exercise anyway. > I've always though that at least something of this level should be possible. > At the very least, figuring out what .h files a file depends upon, by > scanning it for #include commands, could be done at make time. But you Amplify also includes an operation called "reconfigure", which updates both the dependencies and version selection for a configuration, using user defined rules for both. Such rules can, for example, require that changes to source files (such as addition or deletion of include lines) cause the update of dependency information. > Unfortunately, I don't know of anything that does > this right now- Amplify does! > Flint Pellett, Global Information Systems Technology, Inc. > 1800 Woodfield Drive, Savoy, IL 61874 (217) 352-1165 > uunet!gistdev!flint or flint@gistdev.gist.com For information about Amplify you may contact: Caseware, Inc. 3530 Hyland Ave. #115 Costa Mesa, CA 92626 or send e-mail to: amplify@cwi.com Please note that although I work for Caseware, my opinions do not necessarily reflect those of my employer.
kjj@varese.UUCP (Kevin Johnson) (10/07/90)
In article <1990Oct3.000440.5275@hades.ausonics.oz.au> greyham@hades.ausonics.oz.au (Greyham Stoney) writes: >* The Makefile is assumed to reside in the current directory and each Makefile > must contain the rules saying how to make objects, since make's > built-in rules aren't right. We have well over 100 Makefiles in >[...] Yes, the default location for make's dep-file is the current directory, but it's changeable on the command line. This is nothing an alias won't solve. Another trick is to do what imake does and provide a mechanism where a front-end dep-file file is preprocessed with cpp, m4 or whatever... Out of curiosity, in what way are make's builtin rules 'not right'? >* Dependancies must be explicitly listed in the Makefile; and they are never > kept up to date: No ammount of forcing people is going to keep them up > to date, and it's a pretty pointless exercise anyway. In order to > control the rules with which our objects are made, we delta Makefiles > which makes it even worse since to update the depenancies you have to > get the thing for editing. Why can't the dependancies be discerned > from the source file at make time?. Well, if you weren't concerned about the overhead of checking dependancies at make-time I guess you do it that way... I just run makedepend whenever I modify the include directives in a module... >Are there any make-like systems that conquer these two basic problems?. I've starting using dmake, which I got off one of the source groups on USENET (sorry, I don't remember which one). I've been it for about a month now with no real problems. It's a considerable improvement over trad make. I think it's well worth looking into. I got it off on the source groups on USENET. The author's name is Dennis Vadura. The version I got on USENET has a GNU LICENCE file - so. I'm sure some archive has snarfed a copy. #include <standard_disclaimer> .-----------------------------------------------------------------------------. | Kevin Johnson ...!mcdphx!QIS1!kjj | | QIS System Administrator Motorola MCD kjj@phx.mcd.mot.com |
robert@isgtec.UUCP (Robert A. Osborne) (10/09/90)
In article <1990Oct3.000440.5275@hades.ausonics.oz.au> greyham@hades.ausonics.oz.au (Greyham Stoney) writes: >My company is working on a medium-to-large software project for which we use >standard System-V 'make' to specify the rules by which objects are made from >source files, and for specifying the source file dependancies. We're working on a large software project that has to be supported on several platforms (SGI, Sun, Dec) and are using Imake (a tool that comes with X) to define our makefiles. Imake uses cpp and some template files to create a Makefile from an Imakefile. We only need one Imakefile; the proper makefile is created for each platform. > they [his makefiles] all contain the same command to put > an object in a library, although the library name differs. Changing the > name of the librarian utility (if we needed to) would be impossible > (have to change 100+ Makefiles just to do that). The Imakefile would have a rule, say InstallLibrary, that would look like: InstallLibrary(library_name,a.o b.o c.o) This rule could handle everything (the Imakefile might consist of only this line) including installing, compiling debug/optimized, 'clean'ing, making tags, prototypes, etc. When the librarian utility changes a single line is changed in a defaults file and away you go. > Why can't the dependancies be discerned from the source file at make time?. Imake includes 'makedepend' which finds source dependancies (including nested .h's). It can be used to make these dependancies at make time. I would recommend getting a hold of these tools! Rob. -- Robert A. Osborne ...uunet!utai!lsuc!isgtec!robert or robert@isgtec.uucp
pcg@cs.aber.ac.uk (Piercarlo Grandi) (10/10/90)
On 3 Oct 90 00:04:40 GMT, greyham@hades.ausonics.oz.au (Greyham Stoney) said: greyham> My company is working on a medium-to-large software project for greyham> which we use standard System-V 'make' [ ... ] greyham> There are some problems with this however, which lead me to ask greyham> if there is anything better we could use; In particular, 'make' greyham> seems to have the following annoying problems & deficencies: greyham> * The Makefile is assumed to reside in the current directory greyham> * Dependancies must be explicitly listed in the Makefile greyham> Are there any make-like systems that conquer these two basic greyham> problems?. There are several better makes around. My favourite ones (they are free and very good) are: cake It is a kind of logic programming make. it is exceptionally flexible and solves both your problems above quite well. Be warned though that I don't know whether it is in active development, and the documentation is fairly obscure (there is a much nicer article in some EUUG proceedings). It is completely different from make. dmake It is fully compatible with make, under active development, and well documented. I find it a bit slow (it is implemented in some funny way, using C as a string processing language), and much less elegant than cake, even if it is far less unfamiliar. You can use dmake to solve both problems above, but the second with less ease than cake. I have been very undecided between the two. Cake is clearly more elegant, but I would want to add a couple of things that I think would make it more efficient. Dmake is clearly more backwards compatible, and it is under active development, and better documented. Another alternative is GNU make; it is somehow similar in cope to dmake, but, as most GNU things, it is more complicated and less structured than dmake. All these makes are available at finer archive sites (there is a large scale example of cake at vgr.brl.mil, for example). -- Piercarlo "Peter" Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
fjs@bonz.ogo.dec.com (Jay Shields) (10/11/90)
In article <1990Oct3.000440.5275@hades.ausonics.oz.au> greyham@hades.ausonics.oz.au (Greyham Stoney) writes: >* Dependancies must be explicitly listed in the Makefile; and they are never > kept up to date: No ammount of forcing people is going to keep them up > to date, and it's a pretty pointless exercise anyway. [...] > Why can't the dependancies be discerned from the source file at > make time? If you don't have Imake or any of the other tools mentioned, and if you just want to improve your current makefiles, the sample makefile below containes an example of the "depend" target that a few other articles have mentioned. It's a pretty simplistic example, of course, but it should give you the basic idea. The "depend" target can be used pretty much as-is in your Makefiles if you just define the macros correctly. BTW, just in case it's not totally clear from the example below, when you run "make depend", the Makefile will be regenerated with a new set of dependencies for each source file. The old Makefile will be stored in a file called makeback. If there is no difference in the old and new Makefiles, makeback will not be created. Assumptions, Limitations, Notes and other stuff: 1. This works for C code only! 2. Your C preprocessor must support the -M switch (some compilers allow you to get the same results using: cc -Em) 3. The use of @- on the depend rule line may be dangerous. The - (which ignores errors) is needed because the cmp function returns a value of 1 if the two makefiles are different, which will stop the make if the - is not there. If you remove the - for safety reasons, be sure to remove the check for differences between the two makefiles. 4. Lots of others, but give it a shot! 5. No warrantee expressed or implied! 8-)> Makefile: ######################################################################## # CSRC macro defines all of the C programs in you current directory CSRC = fake_prog.c # Use CPP to define your C pre-processor CPP = /lib/cpp # Some cc options should be passed on to the pre-processor (such as -D). # Others (Such as -l) should not. CFLAGS could then be composed of CPP_FLAGS # plus misc. flags. CPP_FLAGS = -Dfakedefine # INCLUDE_LIBS tells the C pre-processor where to look for include files. You # really should have such a macro already defined for use with cc. INCLUDE_LIBS = -I/usr/src/include_dir # Here's the depend target. depend: @-sed '/^###DEPENDENCIES/,$$d' < Makefile > tmp_make ; \ echo "###DEPENDENCIES Follow. Do not delete this line" >> tmp_make ; \ echo >> tmp_make ; \ for i in $(CSRC); \ do \ $(CPP) -M $(CPP_FLAGS) $$i $(INCLUDE_LIBS) | sort -r | uniq >> tmp_make ; \ echo >> tmp_make ; \ done >> tmp_make ; \ echo >> tmp_make ; \ echo "# End of Dependency list" >> tmp_make ; \ echo "# Anything after this line will be deleted" >> tmp_make ; \ echo "# when the next \"make depend\" is done." >> tmp_make ; \ cmp Makefile tmp_make > tmp_compare ; \ if [ -s tmp_compare ] ; then \ mv Makefile makeback ; \ mv tmp_make Makefile ; \ else \ rm -f tmp_make ; \ fi ; \ rm -f tmp_compare ; \ chmod 664 Makefile # ###DEPENDENCIES Follow. Do not delete this line fake_prog.o: fake_prog.c fake_prog.o: /usr/include/stdio.h fake_prog.o: /usr/include/sys/types.h fake_prog.o: /usr/src/include_dir/fake_inc.h # End of Dependency list # Anything after this line will be deleted # when the next "make depend" is done. ######################################################################## The list of dependencies below the ###DEPENDENCIES line are just an example of the type of list generated for each source file. Hope this helps! -- F. Jay Shields "I know how to make friends. How do imake friends?" Digital Equipment Corporation Littleton, MA fjs@bonz.ogo.dec.com (508) 952-3238
locke@nike.paradyne.com (Richard Locke) (10/12/90)
I've heard a rumor that AT&T will be marketing an previously internal version of an improved, new 'make' sometime in the foreseeable future. My intention is to not speak for the company; I don't know if this is an announced product, etc. My best advice is to call your Unix vendor and ask about the new make. If you run into a brick wall, send me some e-mail and I'll see if I can put you in touch with someone who can answer questions. -dick
lowell@tc.fluke.COM (Lowell Skoog) (10/13/90)
In article <1990Oct3.000440.5275@hades.ausonics.oz.au> greyham@hades.ausonics.oz.au (Greyham Stoney) writes: > We have well over 100 Makefiles in > one project; most of which contain basically the same information; but > with minor differences. Several respondents have mentioned the "include" directive of make. I second this recommendation. I recently developed a set of include files for SunOS make that we use at Fluke to maintain local software. These include files define our basic software maintenance process. The working makefiles in each software package inherit the basic process definition and adapt it as needed, usually by just specifying input files and destination directories (using make macros). The include files have all sorts of defaults built in, which can be overridden by any working makefile. If we need to change a default in the future, all working makefiles will automatically be updated. This approach has been a real boon. >* Dependancies must be explicitly listed in the Makefile; and they are never > kept up to date SunOS 4.0 make has a `.KEEP_STATE' feature, which I have seen in no other version of make (unfortunately). When you enable this feature, make automatically creates a state file that records include file dependencies during the make run. It also records command dependencies, so if you run make with CFLAGS=-g, then run it again with CFLAGS=-O, every target that depended on the previous setting of CFLAGS will be automatically rebuilt. I think this is a great feature. ---------------------------------------------------------------------- Lowell Skoog M/S 223B lowell@tc.fluke.COM John Fluke Mfg. Co. Inc. {uw-beaver,microsoft,sun}!fluke!lowell P.O. Box 9090 Everett, WA, USA 98206-9090 (206) 356-5283
meissner@osf.org (Michael Meissner) (10/15/90)
In article <1990Oct12.171347.28996@tc.fluke.COM> lowell@tc.fluke.COM (Lowell Skoog) writes: | > We have well over 100 Makefiles in | > one project; most of which contain basically the same information; but | > with minor differences. | | Several respondents have mentioned the "include" directive of make. | I second this recommendation. .... The only real problem with 'include' is the way it was hacked into make prevents you from having a rule such as: include.o: include.c hdr.h Whoops.... -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Do apple growers tell their kids money doesn't grow on bushes?
sartin@hplabsz.HPL.HP.COM (Rob Sartin) (10/16/90)
In article <1990Oct12.124029.6545@pdn.paradyne.com> locke@nike.paradyne.com (Richard Locke) writes: >I've heard a rumor that AT&T will be marketing an previously internal >version of an improved, new 'make' sometime in the foreseeable future. Actually, AT&T already markets nmake (the "new make"), though not vigorously, through the AT&T Toolchest. Call AT&T for more info. I swear by nmake far more often than I swear at it (though I do occasionally swear at it). Rob
hopper@ntmtv.UUCP (Ian Hopper) (10/16/90)
From article <1990Oct3.000440.5275@hades.ausonics.oz.au>, by greyham@hades.ausonics.oz.au (Greyham Stoney):
I've been tracking the followups to this but have not seen any
mention of the following:
Most Unix C compilers support running CPP in a mode that reports
all dependencies within a source file. (Transitive #include's)
GNU make comes with source, so you can change it as needed.
It has a lot of additional features built in. This is the
easiest apptoach, if the additional features are sufficient.
imake - from the people who wrote X Windows.
This is a thinly-veiled covering over the C pre-processor.
Essentially your make file is maintained as a CPP input file,
you use all of the features of CPP to "generate" your actual
makefile. Nice approach if you are already comfortable with
weird CPP coding.
We are contemplating using options 2 and 3 to maintain 600K+ of code. I would
be interested in people's experiences with these approaches.
--
Ian Hopper {amdahl.com,ames.arpa,hplabs}!ntmtv!hopper
Northern Telecom Inc. [Clever comment under construction.]roger@wrs.com (Roger Rohrbach) (10/18/90)
locke@nike.paradyne.com (Richard Locke) writes: > I've heard a rumor that AT&T will be marketing an previously internal > version of an improved, new 'make' sometime in the foreseeable future. This improved make has been available through the AT&T Toolchest since 1985 as "nmake". I used it for several years to build a huge DBMS on scores of Unix systems. We had to port it to do so, and the code was crappy, and it was a pain. But the GREAT improvement in functionality and the ad vantage of having uniform behavior everywhere makes this the only way to go. lowell@tc.fluke.COM (Lowell Skoog) writes: > SunOS 4.0 make has a `.KEEP_STATE' feature, which I have seen in no > other version of make (unfortunately). > It also records command dependencies Nmake does both of these as well. I think GNU make may incorporate a lot of these ideas; if so, it's a cheap alternative. -- Roger Rohrbach sun!wrs!roger roger@wrs.com - Eddie sez: ----------------------------------------------- (c) 1986, 1990 -. | {o >o | | \<>) "If I were a gas, I'd be inert!" |