jensen%cod@NOSC.ARPA (Layne K. Jensen) (10/16/86)
Has anyone worked out a {slick|convenient|usable|whatever} way of using
Make and RCS with Modula-2? We are using the DEC WRL (Powell) compiler,
and have never been able to really make it all work together in a nice
manner (while making use of SUFFIX, etc). Any help would be appreciated.
Layne Jensen jensen@nosc.arpa
Naval Ocean Systems Center ..ucbvax!sdcsvax!noscvax!jensen
San Diego, CArpd@f.gp.cs.cmu.edu (Richard Draves) (10/16/86)
I haven't tried using RCS with Modula-2 source, but I have worked out a method for using make. Put implementation and program modules in .mod files and definition modules in .def files. Each .mod file will generate a .o file; each .def file will generate a .sym file. The .sym files have 0 bytes and are used only to communicate dependencies. Every .sym file depends on the corresponding .def file and the .sym files of any imported modules. Make it with touch(1). Every .o file depends on the corresponding .mod file and the .sym files of any imported modules. If it is an implementation module is also depends on its own .sym file. Using .sym files forces make to calculate the transitive closure of the imports relation. This way, if A imports B and B (def) imports C, you don't have to have A.o depend on C.def. Instead, A.o depends on B.sym, which depends on C.sym, which depends on C.def. Rich
tynor@gitpyr.gatech.EDU (Steve Tynor) (10/18/86)
I have a program (written in Modula2 on the Atari ST) that takes a main
program name and generates a MAKEFILE by recursively visiting the IMPORTed
files... I'll post it as soon as I'm sure that there are no stupid bugs
left.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
No problem is so formidable that you can't just walk away from it.
Steve Tynor
Georgia Instutute of Technology
...{akgua, allegra, amd, harpo, hplabs,
ihnp4, masscomp, ut-ngp, rlgvax, sb1,
uf-cgrl, unmvax, ut-sally} !gatech!gitpyr!tynorpaul@hslrswi.UUCP (Paul Breslaw) (11/03/86)
In article <8610152351.AA01814@cod.ARPA> jensen%cod@NOSC.ARPA (Layne K. Jensen) writes: >Has anyone worked out a {slick|convenient|usable|whatever} way of using >Make and RCS with Modula-2? We are using the DEC WRL (Powell) compiler, >and have never been able to really make it all work together in a nice >manner (while making use of SUFFIX, etc). Any help would be appreciated. The Cambridge University (UK) 4.2bsd Vax/68000 Modula-2 system has an automatic makefile generator - m2make(1) - which depends on the module lookup mechanism used by the compiler/linker/debugger. This is implemented by means of a simple environment variable M2PATH and searches successive directories for source files (.{def,mod}) and hidden sub-directories of successive directories (.{lnk,sym,ref,key}/module) for compiler output files. M2make scans all modula-2 source files in the current directory only (by default), building a dependency tree. It then outputs the tree in the form of a conventional makefile, with one target per output file. It also groups all the targets into three symbolic targets - 'programs' (for all program modules discovered), 'libraries' (for implementation modules), and 'symbols' (for definition modules). It is also possible to have m2make build targets for modules on the M2PATH but not in the current directory, by providing it with a file that contains a proper subset of the directories of M2PATH. In this way a given makefile can be used, for example, to build a cross library as well as a host library. One side effect of this option with the file of directories is that the makefile may have multiple targets for the same module. It all gets pretty confusing here, so we have settled for the time being on the default action of m2make, plus generally, one makefile per directory for all the directories over which the modules of a program may be distributed. This actually works quite well - for example it manages the Vax compiler itself which contains about 180 modules distributed over 6 or 7 directories. The only handicap is that make must be run in each of the directories *in the right order*, otherwise version conflicts can occur at link time. But its an order of magnitude easier to remember which order to run 6 make's in, than which order to compile 180 modules. We are currently modifying m2make to overcome some of these difficulties and are attempting to integrate it with use of RCS. Here one must separate the goals of version generation (extract the appropriate source files for version 'latest' of program 'foo'), and configuration control (build me a version of the half-finished program 'foo' from bits and pieces scattered over many directories). The former, version generation, is quite straight forward, since, in principle everything can be extracted into one directory, M2PATH is set to '.', run m2make, and then run make. Configuration control, on the other hand, is for us an unsolved problem, although we have piecemeal solutions to certain situations. M2make can be obtained from Peter Robinson at Cambridge UK pr%UK.AC.Cam.CL@CS.UCL.AC.UK