🚀 go-pugleaf

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

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!tynor

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