bobb@gold.gvg.tek.com (Bob Bateman) (01/22/91)
I'm looking for any form of makefile-generating scripts, C source, or related information. The best possible solution would be one that was substantially compiler-independent, and sophisticated enough to work on a project with many source files in many directories, with various libraries, and several permutations of compilation options. I'd appreciate any information the net can provide. ****************************************************************** "Once you write and test the makefile, you can forget about the processing details; make takes care of them..." -excerpt from Sun make User's Guide -- * Bob Bateman Grass Valley Group * bobb@gold.gvg.tek.com P.O. Box 1114 * 916-478-3562 Grass Valley CA 95945
whg@INEL.GOV (Bill Gray) (01/22/91)
In article <1898@gold.gvg.tek.com> bobb@gold.gvg.tek.com (Bob Bateman) writes: >I'm looking for any form of makefile-generating scripts ... Uhhh ... make (?). Couldn't make make other make files? I dunno; just a thought. Bill Gray UUCP: ...!uunet!inel.gov!whg Idaho National Engineering Lab. INTERNET: whg@INEL.GOV "Quantity has a quality all its own." -- Lenin (on the subject of tanks) Disclaimer: My opinions only; obtain a prospectus before you invest. ========== long legal disclaimer follows, press n to skip =========== Neither the United States Government or the Idaho National Engineering Laboratory or any of their employees, makes any warranty, whatsoever, implied, or assumes any legal liability or responsibility regarding any information, disclosed, or represents that its use would not infringe privately owned rights. No specific reference constitutes or implies endorsement, recommendation, or favoring by the United States Government or the Idaho National Engineering Laboratory. The views and opinions expressed herein do not necessarily reflect those of the United States Government or the Idaho National Engineering Laboratory, and shall not be used for advertising or product endorsement purposes.
raja@bombay.cps.msu.edu (Narayan S. Raja) (01/22/91)
In article <1898@gold.gvg.tek.com>, (Bob Bateman) writes:
< I'm looking for any form of makefile-generating scripts, C source, or
How about imake, which is commonly used
with so-called "Imakefiles" in X source
distributions to generate makefiles? For
examples check a few "Imakefiles" in X
source.
Narayan Sriranga Raja.rh@smds.UUCP (Richard Harter) (01/23/91)
In article <1991Jan22.002523.19803@inel.gov>, whg@INEL.GOV (Bill Gray) writes: > In article <1898@gold.gvg.tek.com> bobb@gold.gvg.tek.com (Bob Bateman) writes: > >I'm looking for any form of makefile-generating scripts ... > Uhhh ... make (?). Couldn't make make other make files? I dunno; just a thought. It's a non-trivial problem -- it's really an AI type problem because you need some knowledge about what kinds of things you are making. Our (proprietary) software management system does handle writing makefile writing for classical third generation executables. Briefly, this is the scenario. You are given a set of source files (in one or more directories) and a set of files containing entry points for executables to be built (mains). You need to be able to determine for each main the list of additional object files that will be needed to build the executable. For each object file you need to determine the source file and include files that it will depend upon (the relatively easy part). To determine the list of object files needed you have two choices. One route is to compile each file and fish around in the object file for all of the referenced externals. The other is to scan the source code with language specific scanners that dig out the referenced and declared entry points. In either case, given the cross reference information for the source file set you derive the entry point closure for each main and, from that, the object file set needed for each executable. Given this information, the make file writing is simply an exercise. However life is not that simple. First of all there are external libraries to deal with (this can be finessed). Secondly you may be packaging your own object code into libraries -- this changes the whole dependency analysis problem because on one hand you don't need to derive minimum closures but on the other hand you now have to generate library dependency code for the makefile. Thirdly the above scenario really doesn't deal with intermediate preprocessors, e.g. lex, yacc, and friends. Fourthly there can be data file dependencies that have to be factored in. And, of course, the build may be parameterized by compiler and preprocessor options and parameters. -- Richard Harter, Software Maintenance and Development Systems, Inc. Net address: jjmhome!smds!rh Phone: 508-369-7398 US Mail: SMDS Inc., PO Box 555, Concord MA 01742 This sentence no verb. This sentence short. This signature done.
throop@aurs01.UUCP (Wayne Throop) (01/24/91)
> rh@smds.UUCP (Richard Harter) > It's a non-trivial problem -- it's really an AI type problem because you > need some knowledge about what kinds of things you are making. True. Even make (and descendants) has been called "an expert system for C programmers", with some reason. > Given [..what-includes-what and what-invokes-what (in 3GLs)..] > information, the make file writing is simply an exercise. > However life is not that simple. Understatement if ever I heard one. (And note, in addition to being an "excersize", there are a lot of design decisions embodied in or mediated by makefiles (some of which Richard alludes to, eg, compilation switches)). > [..problems include..] [...] external libraries [...] > [..local code in..] libraries -- this changes the whole dependency > analysis problem [...] intermediate preprocessors, e.g. lex, yacc, > [...] data file dependencies that have to be factored in > [...] the build may be parameterized by [...] options and parameters Now, the library problems can be finessed (as Richard said), data file dependencies are simply more "expert" rules akin to those we started out with for "knowing" about .c and .h files and "main" and all that, and if make would only deal with non-file entities, options and parameters can be viewed as inputs to the compilation (or other transform) process. ( There is also a larger problem for which options and parameters are a special case, and that is different implementations of the same interfaces. There is no general solution other than human packaging choices here, similar to the choice of compile options in the subcase. (Of course, heuristics could be applied, eg, to decide whether a quicksort implementation of a sort interface would be better than a shellshort or heapsort or whatnot, but I really don't see any algorithmic solution for the general case.) (In fact, choosing among algorithms seems like one of those things that's NP complete or equivalent to the halting problem, eh?) ) This leaves us with "intermediate processors", which is also solvable by enhancements to the make engine. In particular, derivation of dependencies must be a co-process and not a pre-process to the automated construction itself. I think this provides a solution to any case that is computable at all. ( Note that to perform well, interweaving derivations and "make"-like construction requires the construction engine to keep more information around in some intermediate format. But such a scheme could be used to mend many deficiencies of make along with this one. ) So, I think none of the problems really standing in our way here are fundamentally intractable. I already have a system which essentially solves the "intermediate processors" problem for source generation (ie, only requires local knowledge of how to derive dependencies, and does not need to know how to extract .c dependencies out of .y and .l files). Extending this to include finding closures from "main" routines (assuming absence of (or disambiguation of) multiple implementations of a given interface) is not prohibitive. There is of course a lot more to the subject (for one example, "automount"-like virtual filesystems that construct out-of-date files when they are open(2)ed for reading), but certainly the current state of "make" technology is anomalously primitive. Wayne Throop ...!mcnc!aurgate!throop
rh@smds.UUCP (Richard Harter) (01/26/91)
In article <59474@aurs01.UUCP>, throop@aurs01.UUCP (Wayne Throop) writes: > > rh@smds.UUCP (Richard Harter) > > It's a non-trivial problem -- it's really an AI type problem because you > > need some knowledge about what kinds of things you are making. [... Many interesting and cogent remarks deleted ...] > There is of course a lot more to the subject (for one example, > "automount"-like virtual filesystems that construct out-of-date files > when they are open(2)ed for reading), but certainly the current state > of "make" technology is anomalously primitive. This touches on one of the many other failings of make which, in this case, is really a failure of the underlying operating system. Many of us, I suppose, have been bitten by moving (mv) a source file from one directory to another and discovering that make does not rebuild the object file in the target directory because the source file date did not change in the move. One could say that the problem is that this is a bug in mv. However the problem is really that the out-of-date check is really a heuristic work-around for the fact that files (in most OS's and UNIX in particular) do not have pedigrees, i.e. there is no way to determine how a file was created. Another common instance of this problem is the situation where the build is parameterized. When we build a target from an object we really need to know both (a) has the object changed, and (b) are we using the same build rule. -- Richard Harter, Software Maintenance and Development Systems, Inc. Net address: jjmhome!smds!rh Phone: 508-369-7398 US Mail: SMDS Inc., PO Box 555, Concord MA 01742 This sentence no verb. This sentence short. This signature done.