[Prev][Next][Index][Thread]
opacs/omake.html
Hello
I put an omake.html in the online doc
with a better text than the mail one.
You could access it from the "Co" doc.
There are also links from the "Installation"
item. I send it below in case of.
About future improvement of this system...
I need the possibility to connect/disconnect
easily the use of a sub-package in a package.
The typical example is Wo. At Orsay it
is reconstructed with the use of
sub-packages like tcl or the first
version of the G4o package, that
I do not want to distribute today.
Each time I do the Wo tar file,
I have to disconnect sub-package in
the Wo.make, Wo/Make.odb and reconstruct
the Makefile for the distrib. It is clear
that I need something more automatic.
An other problem that I shall handle
is to limit the inflation of the environment
variables. The use of inherited "make"
macro clearly is a step in this
direction, but we can do better.
In the way code is organized, we
have the need to :
- separate the sources for
the binaries, than that
of code that go in the libraries.
- change the suffix ".c" files that
contain C code to be included
and not compiled directly
(like the WoXxx.c files)
by the suffix ".ic".
This is to help experiments
(like BABAR) that has adopted
the use of a CVS/GNU makefile
environment to distribute their
packages. They want to incorporate
the distribution of the "o" pacakges
in their system, along with the one
of the event display.
Mainly with few lines
of "GNU make" code it is possible
to handle compilation and
building of a library from
a directory containing only files
for one library.
Their system does not work on
VMS, it needs a strict
directory organisation in case
of multi-packages, it is not
able to have multi-lib from one
source directory, they have not today the
shear lib construction and test programs
must be handled by other GNU makefile,...
But it appears that the upper required
changes, to enter their system, go in the
way of clarifying organisation for one
packages ; then I shall adopt them.
Guy Barrand
<TITLE>The omake tool</TITLE>
<!-- Changed by: Guy Barrand, 19-Jun-1996 -->
<!***************************************************************************>
<A NAME="omake" ><H3>The omake tool</H3></A>
<!***************************************************************************>
<P>
The "omake" system is intended
to handle the automatic UNIX Makefile
(or VMS descrip.mms) production for
multi-package environment.
<P>
In the following I assume
that your have a package Xxx that
need the sub-packages Yyy, Zzz to be
reconstructed.
<P>
For example in the Makefile of Xxx,
you have to add in the C compile command
the -I options to get the include files
of the Yyy, Zzz packages. In the load
command you have to specify the
libraries of Yyy, Zzz, etc...
<P>
For each package (Xxx, Yyy, Zzz) must
exists an ".make" file that set
"make" macros for this package :
<PRE>
Xxx.make
Yyy.make
Zzz.make
</PRE>
For the "o" packages, the ".make" files
are traditionnaly put in the "mgr" directory
of the package.
<P>
The idea is that Xxx inherits the "make"
description of the sub-packages Yyy, Zzz.
This is done by using the "include" directive
of the "make" tool. Then after its production by
"omake", the Xxx Makefile begins with :
<PRE>
#!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
# Produced by:
# UNIX> $COBIN/omake.exe
# using file Make.odb.
#!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
include Begin.make
include ${ZZZMGR}/Zzz.make
include ${YYYMGR}/Yyy.make
include Xxx.make
...
</PRE>
YYYMGR, ZZZMGR are environment variables
that permit to find the sub-package
".make" files.
<P>
The second idea of "omake" is to
produce in the Makefile (descrip.mms)
the dependencies and commands
to compile sources, build libraries
(shearable versions, if possible !),
and build binaries for the Xxx package.
The system must be able to handle the
case where more than one library
and one binary could be produced for
one package.
<P>
Then how it works ? Mainly "omake" read
a "Make.odb" file and produce a "Makefile"
for UNIX and a "descrip.mms" for VMS.
<P>
For the "o" packages, the "Make.odb",
"Makefile", "descrip.mms" files are
traditionnaly put in the "mgr" directory
of the package.
<P>
The "Make.odb" is made of an object
"Make" and a collection of "OModule" objects.
The "Make" object has two properties :
<UL>
<LI> package : your give the package name.
<LI> use : your give the list of packages
used by Xxx. For these sub packages
a ".make" must exists.
</UL>
For example, in the Xxx "Make.odb" your
could have :
<PRE>
!----------------------------
begin Make
package = Xxx
use = Yyy Zzz
end
</PRE>
With the "use" property of the "Make" object
"omake" produces in the Makefile the
"include" directives to handle "make"
inheritance. With the upper example :
<PRE>
...
include Begin.make
include ${ZZZMGR}/Zzz.make
include ${YYYMGR}/Yyy.make
include Xx.make
...
</PRE>
Here it is assumed that Yyy depends of Zzz.
<P>
After the "Make" object, you put
a collection of "OModule" objects
that describe your libraries, binaries,
and sources.
<P>
Each OModule has a "type" property.
Possible values are :
<UL>
<LI> "src" : it is the default value.
The module is a source file to
be compiled. Default language is C.
You can change it with the "lang"
property. Exa : lang = f77.
A recent patch of Co take into account
"lang = c++". If the module name
is "xxx", a source file must exists
in a source directory according
to the language type.
Exa : xxx.c by default.
The "inLib" property specifies
in which library you want to put
the result of the compilation.
If not specified, the object file
is produced and lets in the binary
directory.
<LI> "ar" : the OModule is a library
in the "archive" form. It is
constructed in the binary directory.
<LI> "sl" : the OModule is a library
in the shared form. "omake"
produces code to try to build
the shared lib from the archive lib
with the Co "maklibs.sh" command file
("maklibs.com" for VMS).
On some system, to build shared
versions, it is necessary to
explicitly specify the other library
dependencies. You can do it with
the "libs" property.
<LI> "bin" : the OModule is a binary.
The source file is specified
in the same way that for an "src"
module. With the help of the "objs" and
"libs" properties, that specify the
objects and libraries to link with,
"omake" produces a load command
to construct the program in the bin
directory.
</UL>
In the produced "Makefile" the source
and binary directories are specified
with the macros $(src) and $(bin).
These macros has to be defined somewhere
in one of the inherited ".make" file.
<P>
A little example :
<PRE>
!----------------------------
begin Make
package = Xxx
end
!----------------------------
begin OModule
name = xxxT
type = bin
objs = yyy
libs = libXxx libaaa libbbb
end
!----------------------------
begin OModule
name = libXxx
type = sl
libs = libaaa libbbb
end
!----------------------------
begin OModule
name = xxx1
inLib = libXxx
end
!----------------------------
begin OModule
name = xxx2
inLib = libXxx
end
!----------------------------
begin OModule
name = yyy
lang = f77
end
</PRE>
Here we assume than there exists
in a source directory :
<PRE>
xxxT.c
yyy.f
xxx1.c
xxx2.c
</PRE>
We want to put xxx1.o and xxx2.o
in the shared lib libXxx.
We want to reconstruct the program
xxxT.exe by linking with the object
yyy.o (not in the lib), the
package lib libXxx and other
"external" libs libaaa, libbbb.
<P>
Looking in the produced "Makefile"
(descrip.mms) you see that
most of the symbols are used as "make"
macros. For exa : libaaa in "Make.odb"
is used as $(Xxxlibaaa) in the
Makefile. IT IS THE ROLE OF
THE ".make" FILES TO SPECIFY THESE MACROS.
"omake" does nothing here. In the
".make" files, macros could be defined directly,
by reference to macros inherited
from other ".make" file or from
environment variables.
<P>
For the "o" packages the environment
variables are defined with the "pack_config"
system that read the "requirements" file
and produces the "setup" files.
<P>
Experience shows that it is sufficently
flexible to handle "Makefile" production for
a multi-package, multi-librariess,
multi-binaries, development environment.
<P>
Except the intensive use of macros,
most of the tricks of "make"
(and especially GNU make) has been
avoided. We want that the "Makefile"
produced be readable with a minimum
knowledge of the "make" syntax.
<P>
Look in the "mgr" directories of the
"o" packages for examples of ".make"
and "Make.odb" files.
<HR>