Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!spool.mu.edu!uunet!dg-rtp!webo!dg-webo!pds From: pds@lemming.webo.dg.com (Paul D. Smith) Newsgroups: comp.sources.wanted Subject: Re: anyone want to redesign make? Message-ID: Date: 19 Apr 91 00:26:35 GMT References: Sender: usenet@webo.dg.com (Usenet Administration) Distribution: comp.sources.wanted Organization: NSDD/ONSD, Data General Corp., Westboro, MA Lines: 172 In-Reply-To: slehar@park.bu.edu's message of 18 Apr 91 14:58:35 GMT This discussion is totally improper for comp.sources.wanted, put a quick perusal didn't turn up another good group: makefiles exist on PCs as well as UNIX, so ... if anyone has an idea, please let me know. [] On 18 Apr 91 14:58:35 GMT, slehar@park.bu.edu (Steve Lehar) said: SL> There are two major problems with the current concept of make and SL> makefiles. I was wondering whether anyone else sees these problems, SL> and whether anyone has addressed them already, or even, whether anyone SL> wants to fix the make problem. I agree that there are problems with make, but I don't agree with most of the rest of your post; here's why: SL> The first problem with the make concept is that although the source SL> code is often nearly useless without it's makefile, the makefile SL> resides primarily in a directory, whereas the source code should be SL> free to travel around as needed. If I wish to copy a program from one SL> directory to another, I must not only copy the source and all its SL> dependancies, but I must also cut the pertinant lines from the SL> makefile in the source directory and paste them into a makefile in the SL> destination directory. Of course any symbolic definition conflicts SL> must be resolved. I'm really afraid I don't see what you're talking about: why don't you just copy the whole makefile as well? Then you'll have the sources and the makefile and everything will work just fine. Right? Unless you're talking about using the same source files in two different programs which have different makefiles: and then why not use libraries or some such? At the very least, free programs which will produce makefiles for you are abundant on the net... Or maybe your makefiles use full pathnames instead of relative pathnames, which is a no-no anyway: at least make the path prefix be a variable so you can modify it easily. SL> The second problem with makefiles is their syntax, which is so SL> complicated and obscure that even system managers and unix gurus have SL> trouble with them unless they adhere rigidly to their own personal SL> conventions. I wouldn't go *that* far, but I do agree that makefile syntax is less than ideal, especially in older make implementations which are incredibly fussy about strange things. New make programs (esp. things like GNU make) are much better. SL> ... The problem, I have decided, is all of the automatic 'helpful' SL> things that make does for you behind your back without being SL> explicitly asked to do, such as assuming default dependancies and SL> assuming specific file extensions and automatically naming output SL> files and so forth. This is one of the *best* features of make. Taking this out would leave make relatively useless. These things are really trivial to understand if people take the time to learn them; the simple rule is: if there's no rule specified, then make will try to pick one from its list of default rules. Which one is easily determined by looking at the syntax of the TARGET and the first DEPENDANCY. Then match them up with the default rules listed in the man page (or you can make make produce its default rule set itself). Or better still, run it & see which one it uses. One of the biggest problems with make is there is no good manual--see the GNU make product for a decent manual. However, even most make man pages list the default ruleset. SL> These work fine when they work fine, but when SL> they don't they become the devil to debug because they are SL> hidden. True, sort of, see above and below... SL> The simple solution would be to make the make function SL> much more simple and direct, a "whizzywig" approach, what you see SL> is what you get. Something like: SL> /* %M NAME program */ SL> /* %M DEP program.c subr.o */ SL> /* %M EXECUTE cc -o program program.c subr.o */ SL> /* */ SL> /* %M NAME subr */ SL> /* %M DEP subr.o */ SL> /* %M EXECUTE cc -c -o subr.c */ SL> An additional advantage of this approach is that it would make the SL> make program much easier to write. This is even worse than the last! All the flexibility is gone!! Given your scheme, how would I then add a -DDEBUG option to the command line? How would I compile it for profiling or debugging or even optimization? I would have to go through each source file and change it! Ugh! Putting make commands in the source file, for anything except trivial one-file programs, is just asking for disaster once something changes. ---------------------------------------- There are programs (public-domain ones) which can build a reasonable makefile for you with no trouble at all. Heck, even my compiler (gcc) can output a simple make dependancy line: - foo.c -------------------- #include #include #include "foo.h" #include "bar.h" ... -------------------- foo.c - % gcc -MM foo.c > makefile % cat makefile foo.o : foo.c foo.h bar.h % make foo.o cc -c foo.c % ---------------------------------------- Here's my list of problems with make: * I *hate* the fact that the TAB character is the delimiter for rules. What sadist thought of having an invisible character be so important? Even a trivial change like "all rules must begin in column 1; any subsequent lines not beginning in column 1 are continuations of the rule" would be a vast improvement, and wouldn't break hardly any existing makefiles. With the advent of editors which don't necessarily put a ^I in your file when you hit TAB, the TAB delimiter rule is a pain. * make programs could use a good dose of advanced error reporting! Most make programs output such cryptic errors when something happens that it's impossible to figure out from the message what (or even where) the problem really is. * make was not designed to work in large environments, i.e. ones where the source is spread out in many different directories. In particular, I'd like to be able to do something like: 1) Have a "stable" directory with valid, stable source in it. 2) Have a working directory in which exist only the files I'm modifying. 3) When I build, have make build a local copy of the target if I have a local copy of the dependancy. If not, then make should use the stable version of the target if it exists. If it doesn't, make should build a local copy of the target from the stable dependancy. Basically, I want make to "do the right thing" when I have only some of the source files in my working directory: it should never build anything in the stable directory, and it should use everything in the stable directory except what I have actually modified in the working directory. I have never been able to get this to work. If you think you have a way to do it, please: send me an example makefile! I'm not adverse to using more advanced make features such as those found in GNU make, either. paul ----- ------------------------------------------------------------------ | Paul D. Smith | pds@lemming.webo.dg.com | | Data General Corp. | | | Network Systems Development Division | "Pretty Damn S..." | | Open Network Systems Development | | ------------------------------------------------------------------