🚀 go-pugleaf

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