Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!bu.edu!slehar From: slehar@park.bu.edu (Steve Lehar) Newsgroups: comp.sources.wanted Subject: anyone want to redesign make? Message-ID: Date: 18 Apr 91 14:58:35 GMT Sender: news@bu.edu.bu.edu Distribution: comp.sources.wanted Organization: Boston University Center for Adaptive Systems Lines: 75 There are two major problems with the current concept of make and makefiles. I was wondering whether anyone else sees these problems, and whether anyone has addressed them already, or even, whether anyone wants to fix the make problem. The first problem with the make concept is that although the source code is often nearly useless without it's makefile, the makefile resides primarily in a directory, whereas the source code should be free to travel around as needed. If I wish to copy a program from one directory to another, I must not only copy the source and all its dependancies, but I must also cut the pertinant lines from the makefile in the source directory and paste them into a makefile in the destination directory. Of course any symbolic definition conflicts must be resolved. The solution would be simple- the makefile should be appended to the front of the source code, like a header, carefully shielded from the compiler by comment delimiters, and flagged by specific makefile delimiters. For instance, "program.c" might contain the lines... /* %M program: program.c subr.c */ /* %M cc -c -o subr.o subr.c */ /* %M cc -o program program.c subr.o */ where %M, for instance, could flag the make program to interpret these lines, while the /* */ would flag the compiler to ignore these lines. With this simple modification, the source code itself would contain the information about all its dependancies, and compilation instructions. You could now copy programs from one directory to another without having to touch any makefiles. You could even write a simple "copy with dependancies" command that would copy the original source and automatically copy all the dependancies with it. So, for instance, the command... cwd dir1/program.c dir2 would automatically copy program.c and subr.c into dir2, and complain if it found a dependancy missing. The second problem with makefiles is their syntax, which is so complicated and obscure that even system managers and unix gurus have trouble with them unless they adhere rigidly to their own personal conventions. (When you ask them why your makefile doesn't work, their response is always "Why are you doing it like that? Try doing it this way" to which you reply "Because the last guy said 'Why are you doing it like that? Try doing it this way' and I did!") The problem, I have decided, is all of the automatic 'helpful' things that make does for you behind your back without being explicitly asked to do, such as assuming default dependancies and assuming specific file extensions and automatically naming output files and so forth. These work fine when they work fine, but when they don't they become the devil to debug because they are hidden. The simple solution would be to make the make function much more simple and direct, a "whizzywig" approach, what you see is what you get. Something like: /* %M NAME program */ /* %M DEP program.c subr.o */ /* %M EXECUTE cc -o program program.c subr.o */ /* */ /* %M NAME subr */ /* %M DEP subr.o */ /* %M EXECUTE cc -c -o subr.c */ An additional advantage of this approach is that it would make the make program much easier to write. So, anyone want to try it, or has it already been done? -- (O)((O))(((O)))((((O))))(((((O)))))(((((O)))))((((O))))(((O)))((O))(O) (O)((O))((( slehar@park.bu.edu )))((O))(O) (O)((O))((( Steve Lehar Boston University Boston MA )))((O))(O) (O)((O))((( (617) 424-7035 (H) (617) 353-6741 (W) )))((O))(O) (O)((O))(((O)))((((O))))(((((O)))))(((((O)))))((((O))))(((O)))((O))(O)