muller@src.dec.com (Eric Muller) (06/15/91)
This article is my proposal for the organization of future releases of
SRC Modula-3. Please read it and post your comments so that we can
achieve a satisfactory release mechanism.
There are three main goals for the new organization.
The first goal is to break the distribution in smaller pieces. The
current release is monolithic, and this limits the rate of evolution.
In the new scheme, we would like to have library components (and
program components) that can be released independantly. This will
become very useful as some libraries and programs are now stable,
while others will evolve much faster.
The second goal is to make as few assumptions as possible about the
underlying operating system. For example, the current release makes
heavy use of symbolic links and the distribution itself has some; also
we have not been very careful about file name length and such things.
The third goal is to make the imake machinery available to all
Modula-3 users. Imake provides a simple and portable mechanism to
write descriptions of software systems, leaving out most (if not all)
the details that depends on the architecture and the site
configuration. The motivation here is to have Imakefile that are
portable, so as to facilitate the exchange of Modula-3 software.
SOURCE GROUPS
A source group is small collection of related interfaces and modules. For
example, the rd group contains the Rd, UnsafeRd and RdClass interfaces
and the RdRep module. Another example is the Cstd group that contains
the Modula-3 translations of the ANSI-C standard include files.
Source code that differs for different architectures, will go in
separate groups. For example, the Csetjmp interface (the
counterpart of the setjmp.h ANSI-C standard include file) depends on
the architecture. In this case, we would have one group for each
kind of architecture, with the appropriate version of Csetjmp in each.
The group Cstd.generic would contain Cstdlib.i3 (which is
architecture-independant), and the groups Cstd.{VAX,DS3100,SPARC,...}
would each contain the appropriate version of Csetjmp.i3.
Another case to consider is when "architecture" is too fine grained.
For example, the implementation of Random.Real depends on the
representation of floating point numbers and we have two versions
today: for VAX-like machines and for IEEE machines. To minimize the
maintenance headache, we would like to have only two groups instead
of one for each architecture. So we would have the group
random.generic with the interface Random and the module Random that
implements all of Random but the function Real; random.IEEE with the
module RandomIEEE that implements just Random.Real, for IEEE machines;
and random.VAX with the module RandomVAX that implements just
Random.Real, for VAX-like machines.
Each source group has an Imakefile, which describes the contents of
the group; for example:
rd/Imakefile:
public_interface (Rd)
public_interface (UnsafeRd)
public_interface (RdClass)
implementation (RdRep)
Cstd.VAX/Imakefile:
public_interface (Csetjmp)
Cstd.DS3100/Imakefile:
public_interface (Csetjmp)
Here is an initial set of possible entries in these Imakefiles:
interface (i) # Modula-3 interface in i.i3
implementation (m) # Modula-3 module in m.m3
module (m) # = interface (m) + implementation (m)
public_interface (i) # = interface (i) + make it available
in /proj/m3.<architecture>/pub
public_module (m) # = public_interface (m) + implementation (m)
C_object (c) # C source file in c.c
S_object (s) # assembly source file in s.s
lib_export (f) # make f available in
/proj/m3.<architecture>/lib
man_page (p,s) # man page f.man in section s
These Imakefiles can also contain values for the Modula-3 and C
compilation flags:
M3FLAGS = <m3 flags>
CFLAGS = <cc flags>
Whenever source files in this group are compiled, <m3 flags> are
passed to the m3 driver. Similarly for C files with <cc flags>.
LIBRARY AND PROGRAM GROUPS
To build a program or a library, one collects the source files from a
bunch of source groups, compiles and combines them. Each program or
library has its own source group with at least an Imakefile which
mentions the source groups it should be built from. For example, the
Imakefile for the libm3 group (the equivalent of the today's libm3core
library) is:
group (fmt)
group (scan)
group (coreos.ARCHITECTURE)
group (float)
group (main)
group (runtime)
group (text)
group (thread)
group (time)
group (word)
group (Cstd.generic)
group (Cstd.ARCHITECTURE)
group (Csupport)
group (Csupport.ARCHITECTURE)
#if defined (IBMRT) || defined (AIX386) || defined (UMAX)
group (Csupport.strtod)
#endif
group (convert.generic)
#if defined (ARM) || defined (HP300) || defined (AIX386) || defined (IBMR2)
group (convert.int)
#else
group (convert.address)
#endif
library (libm3)
'group (foo)' means that the objects obtained from the compilation
of the sources in the source group 'foo' are to be part of the
library.
'library (libm3)' means put the collected objects in libm3.a.
A few symbols are defined by the templates so that it is easy to
conditionalize selection of a group by architecture:
VAX, IBMRT, ... defined if the current architecture is Vax, IBM-RT, ...
ARCHITECTURE the architecture name (e.g. VAX, IBMRT)
UNIX the name of the Unix interface library (e.g. ultrix-3-1)
HAVE_X11R4 defined if X11R4 is installed on the system
LIBXAW, LIBXMU the names of the corresponding X libraries
LIBXEXT LIBXT
LIBX11
This list of symbols is not exhaustive. New names will be added as
the need occurs.
The Imakefile for a program is very similar to that of a library; the
main difference is that the last line reads 'program (pgm, <libraries>)'.
There is the relatively common case of simple programs for which it
would be overkill to have separate source and program groups. For
example, the tetris program is made of only one module. In that case,
there would be one group with the following Imakefile:
tetris/Imakefile:
LIBS = -lm3misc \
-lm3Xaw -lm3Xt -lm3X11 \ # Modula-3 binding libraries to X
LIBXAW LIBXMU LIBXEXT LIBXT LIBX11 # actual X libraries
implementation (tetris)
program (tetris, $(LIBS))
The groups we have described so far are all sources only. Note that
the organization is very simple: a group just contains a bunch of
files, no subdirectories. The collection of groups is not organized
in any particular way. This should make the mapping of groups to file
system easy on any machine.
DERIVED GROUPS
For each library or program group, there will be a derived group for
each configuration (that is, those that are available at the site).
These derived groups contain an automatically-generated makefile, the
intermediate objects that result from the compilation of the source
files, and the resulting library or program. "Configuration" in the
first sentence means "architecture with compilation switches". For
example, one could have the libraries compiled with debugging info for
DS3100, compiled with optimization for DS3100, compiled with debugging
info for VAX.
The makefile in derived groups allows to build the library or program,
as well as the man pages and other derived files, to install them
using the site template to determine where to install.
EXAMPLE
Let's see what are the groups and their contents for the current
libm3io library:
source:
autoflushwr
Imakefile
AutoFlushWr.i3
AutoFlushWr.m3
pickles
Imakefile
Pkl.i3
Pkl.m3
libm3io ; or m3io or io ?
Imakefile
derived:
libm3io.DS3100.g ; compiled for debug
makefile
AutoFlushWr.io
AutoFlushWr.mo
Pkl.io
Pkl.mo
libm3io.a
libm3io.ma
lim3io.DS3100.O2 ; compiled optimized
...
SRC MODULA-3
We have now reached the limits of the current release scheme; in
particular, adding say 5 new architectures will make the whole thing
just too complex to be reliable.
The release will be broken in the following pieces:
- bootstrap:
imake + templates + example site templates, compiler and driver for
bootstrap. One piece for each architecture. Contains the compiler
and the driver in C (intermediate files). These pieces are intended
for bootstrap only and therefore can be extremely simple, thus
make boostrap very easy. Probably one directory for each program
with all the necessary C files, so that compilation can be as
simple as "cc -o m3compiler *.c".
- for each library and program (including the compiler):
source groups for that library or program.
--
Eric.janssen@parc.xerox.com (Bill Janssen) (06/25/91)
Would you be so kind as to compare and contrast the M3 `imake' with the X Window System `imake'? I seem to be doing a lot of work with the latter (that is, many packages are showing up that use it), and I'd hate to get involved with a different but similar system that used the same name. Bill -- Bill Janssen janssen@parc.xerox.com (415) 494-4763 Xerox Palo Alto Research Center 3333 Coyote Hill Road, Palo Alto, California 94304
muller@src.dec.com (Eric Muller) (06/26/91)
In article <1991Jun24.180621.19438@parc.xerox.com>, Bill Janssen asks: > Would you be so kind as to compare and contrast the M3 `imake' > with the X Window System `imake'? I seem to be doing a lot of > work with the latter (that is, many packages are showing up that > use it), and I'd hate to get involved with a different but similar > system that used the same name. The 'imake' for M3 is the same as the 'imake' for X11. The big difference is in the templates. The goal is to have Imakefiles that are as descriptive as possible (by opposition to imperative), so that we can avoid the some of the troubles that people have with X Imakefiles. In any case, the executable 'imake' will be hidden in Modula-3 library directories, and the 'public' executable will be 'm3make'. -- Eric.
janssen@parc.xerox.com (Bill Janssen) (06/27/91)
And the Andrew folks think that they have solved the world's problems, as well, with *their* own set of Imake templates. Can one specify in an Imakefile the "template standard" which it is written to conform to? This reminds me of DTDs in SGML... Bill -- Bill Janssen janssen@parc.xerox.com (415) 494-4763 Xerox Palo Alto Research Center 3333 Coyote Hill Road, Palo Alto, California 94304
schwartz@groucho.cs.psu.edu (Scott Schwartz) (06/27/91)
janssen@parc.xerox.com (Bill Janssen) writes:
And the Andrew folks think that they have solved the world's
problems, as well, with *their* own set of Imake templates.
And the InterViews folks have *their* own set, and so on and so on and
so on. Doesn't it seem like Imake is the C++ of configuration tools?