[Prev][Next][Index][Thread]
opacs/v2/omake
Hello
The "omake" system is intended
to handle the automatic Makefile
production for multi-package
environment.
In the following I shall assume
that your have a package Xxx that
need the sub-packages Yyy, Zzz to be
reconstructed.
For example in the Makefile you will
have to add in the C compile command
of Xxx, the -I options to get the include files
of the Yyy, Zzz packages to compile.
In the load command you have to specify
the libraries of Yyy and Zzz, etc...
For each package (Xxx, Yyy, Zzz) we have
in the mgr directory a ".make" file
describing "make" macros for this package.
Then :
Xxx/virj/mgr/Xxx.make,
Yyy/virj/mgr/Yyy.make
Zzz/virj/mgr/Zzz.make
must exists.
The idea is that Xxx inherit the "make"
description of the sub-package Yyy, Zzz.
This is done by using the "include" directive
in the Makefile.
Then for example after generation by omake
the Xxx/virj/mgr/Makefile will have at the
begin :
#!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
# Produced by:
# UNIX> $COBIN/omake.exe
# using file Make.odb.
#!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
include Begin.make
include ${ZZZMGR}/Zzz.make
include ${YYYMGR}/Yyy.make
include Xxx.make
...
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 hanlde the
case where more than one libraries
and one binaries could be produced for
one package.
Then how it works ?
Mainly omake.exe read a Xxx/virj/mgr/Make.odb
file and produce a "Makefile" for UNIX
and a "descrip.mms" for VMS.
The Make.odb is made of
an object "Make" and a collection
of "OModule" objects.
The "Make" object has two properties :
- package : your give the package
name.
- use : your give the list of packages
used by Xxx. These sub packages
must follow the same logic as Xxx.
For example, in Xxx/virj/mgr/Make.odb your
could have :
!----------------------------
begin Make
package = Xxx
use = Yyy Zzz
end
With the "use" property of the "Make" object
omake.exe will produce in the Makefile the
"include" directives to handle "make"
inheritance. With the upper example :
...
include Begin.make
include ${ZZZMGR}/Zzz.make
include ${YYYMGR}/Yyy.make
include Xx.make
...
Here it is assumed that Yyy depend of Zzz.
After the "Make" object, you put
a collection of "OModule" objects
that describe your libraries, binaries,
and sources.
Each OModule has a "type" property ;
possible values are :
- "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.
Recent patch of Co take into account
lang = c++ !. If the module name
is "xxx", a source file will
be search in the "src" directory
according to language type. Exa :
src/xxx.c by default.
The "inLib" property specify
in which library you want to put
the result of the compilation.
If not specified, the object file
is produced and let in the "bin"
directory.
- "ar" : the OModule is a library
in its "archive" form. It is
constructed in the bin directory.
- "sl" : the OModule is a library
in its shared form. omake
will produce code to try to build
the shared lib from the archive lib
with the Co/mgr/maklibs.sh or
Co/mgr/maklibs.com on VMS.
On some systemm, to build shared
versions, it is necessary to
explicitly specify the other libraries
dependencies. You can do it with
The "libs" properties
- "bin" : the OModule is a binary.
The source file will be search
in src in the same way that for "src"
module. With the help of the "objs" and
"libs" properties that specify the
objects and libraries to link with,
omake will produce a load command
to construct the program in the bin
directoy.
A little example :
!----------------------------
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
Here we assume than there exists
an :
Xxx/virj/src/xxxT.c
Xxx/virj/src/yyy.f
Xxx/virj/src/xxx1.c
Xxx/virj/src/xxx2.c
We want to put xxx1.o and xxx2.o
in the shared lib libXxx.
We want to reconstruct the
program xxxT by linking with
the object yyy.o (not in the lib)
and the package lib libXxx and
other external libs libaaa, libbbb.
Looking in the produced Makefile
(descrip.mms) you will see that
most of the symbols are used as "make"
macros. For exa : libaaa in Make.odb
will be used as $(Xxxlibaaa) in the
Makefile. IT IS THE ROLE OF
THE Xxx.make TO SPECIFY THESE MACROS.
omake does nothing here.
In the Xxx.make some macros are
defined directly or by reference to
macros inherited from other ".make" file
or from environment variables defined
with the complementary
(requirements, pack_config) system.
Experience shows that it is sufficently
flexible to handle the Makefiles in an
multi-package, with multi-librariess and
multi-binaries, development environment.
It is clear that you can look at the
".make" and Make.odb of the opacs for
examples.
I am going to put the upper text in
the online doc.
Best wishes
Guy Barrand