Possibility to investigate a primary of not yet loaded particle (I.Hrivnacova)

[u/mrichter/AliRoot.git] / build / README

****************************************************
*                                                   *
*         Flat makefile for AliRoot                 *
*                                                   *
*   This README describes how to use the             *
*   Makefile.flat for AliRoot                       *
*                                                   *
*   Author: Jan-Erik Revsbech <revsbech@fys.ku.dk>  *
*****************************************************

** RUNNING **

Use these makefile with

make -f Makefile.flat


** DESCRIPTION **

As the name suggests this is a flat makefile structure for
Aliroot. That means that there is only one makefile for aliroot and
not as before on makefile for every package. This way the
Makefile.flat knows about all dependencies and does not have to
recursively go through all directories several time.

Instead of having a makefile for each package, all the packages have
one module.mk file. This file contains information about the package.
Each package can contain several libraries
and binaries to be made. The module.mk file is automatically created
by a script, by using a template. The script must know about what
files each desired library or binary consists of. This is specified
in .pkg files. For example a module in directory STEER could make two
libraries libSTEER and libSTEERDummy.so and one binary called
STEERTest. In this example the directory STEER would contain three
files: libSTEER.pkg, libSTEERDummy.pkg and binSTEERTest.pkg. These
files will contain information about which source and header files the
library or binary consists of and specific options. See the section package file for
further information about what the pkg files contains.
The libraries are put in the directory LIBPATH, set in Makefile.flat
and binaries in BINPATH. These directories are set to
bin/tgt_$ALICE_TARGET and lib/tgt_$ALICE_TARGET respectively.
In this example we would produce three outoutfiles called libSTEER.so,
libSTEERDummy.so and STEERTest. These names are created from the name
of the .pkg files!!

The module.mk files will be automatically generated by Makefile.flat
if they do not exist. Also the build/moudle.dep contains a list of
dependencies for the module.mk files. This means that for the above
example the build/module.dep would contain a line like this:

STEER/module.mk:   libSTEER.pkg libSTEERDummy.pkg binSTEERTest.pkg

In this way if a change is made to one of the package-files (a
source-file is added or something), the module.mk file will be re-generated.

The Makefile.flat has in the start a variable called MODULES, this
variables lists all the subdirectories to look for module.mk files.

** PACKAGE FILES **

The .pkg files uses make syntax, so be careful with tabs!!!

As a minimum all package files must specify which source-code files and
headers it consist of. This is done with the variables
HDRS,SRCS,FSRCS,CSRCS which is Heades, C++ sources, Fortran sources
and C-source-files.

For example the Package libSTEERDummy.pkg could consist of 

SRCS:= AliSTEERDummy.cxx

FSRCS:= AliSTEERFortranRoutines.f

HDRS:= AliSTEERDummy.cxx

Since the pkg files use make syntax HDRS can also be specified as

HDRS:=$(SRCS:.cxx=.h)

which is useful if there is a lot of files.

If the library (or binary) uses include files in other directories
than its own it should be specified in the variable EHDRS (for External
headers). By default the Makefile.flat will look in $ALICE_ROOT,
$ALICE_ROOT/MODULE (in this case $ALICE_ROOT/STEER), $ROOTSYS/inlude
and in $ALICE_ROOT/include. If more include directories is needed it
can be specified with the variable EINCLUDE. *DO NOT* put the -I flag
it will be put automatically, just write the name of the directory.

If the package exports any header files fo use by other libraries it can be put
in the variable EXPORT. These files will be copied to	
$ALICE_ROOT/include and can be used by other libraries without directly
including this module.

If a root dictionary file is used it can be specified with

DHDR:= STEERLinkdef.h

This will be processed with rootcint with all the header-files
(specified in HDRS), and default cint includedir (set in CINTFLAGS)
plus the directories specified in EINCLUDE

By default all libraries are linked against libraries specified in
SHLIB and binaries against LIBS. If desired extra libraries can be
specified with the ELIBS variable. *DO NOT* specify the -l flag, just
write the library like

ELIBS:= CONTAINERS

this will be translated into -lCONTAINERS

Extra library directories can be specified with ELIBSDIR

If very special compilation flags is needed it can be specified with
the three variables:

PACKFFLAGS:=
PACKCXXFLAGS:=
PACKCFLAGS:=

*WARNING* if these flags are set, the default FFLAGS,CXXFLAGS and CFLAGS
 will be overwritten. Normally they  will be used like this:

PACKCXXFLAGS:= $(filter-out -O%,CXXFLAGS) 

This will set the C++ compiler-flags to the default ones, but without
optimisation.

** LIST OF Variables in .pkg files **

SRCS:=
HDRS:=
FSRCS:=
DHDR:=
CSRCS:=
CHDRS:=
EINCLUDE:=
ELIBS:=
ELIBSDIR:=
PACKFFLAGS:=
PACKCXXFLAGS:=
PACKCFLAGS:=
EXPORT:=
EHDRS:=


** ADDING NEW DIRECTORIES **

When adding a new direcotry you must make a new .pkg file. If your
library is going to be libEXAMPLE.so then make a new file called
libEXAMPLE.pkg in the new direcotry. Now you need to add this
direcotry to the Makefile.flat. Add it to the MODULES variable.
A last step is to edit the build/module.dep file. Add a line like
this:

NEWDIR/module.mk: libEXAMPLE.pkg

Please let the module.mk file depend on all .pkg files in the new
directory. If you want aliroot to be linked against it, then edit
ALIROOT/binaliroot.pkg and add you new lirbrary to the ELIBS variable.