After unzipping one a :
<kit>_source-<version>.zip
go under the directory
OpenScientist/<kit>/obuild
and follow instructions found in the README file or in the below sections. The build should produce at end a binary .zip file similar to what is found under the download area. To use the kit then follow the same instructions than the ones under Install a zip binary kit and Setup and use a kit.
To build from source an OpenScientist kit on a UNIX, after unziping do :
UNIX> cd OpenScientist/<kit>/obuild
sh> . ./setup.sh # to setup the build environment.
( csh> source setup.csh )
UNIX> ./sh/build # to build the per package binaries.
UNIX> ./sh/build -group <driver> # to build the per package binaries
# related to a driver.
UNIX> ./sh/build_release # to build the binary .zip file
# in the ../bin_obuild directory.
and on a Windows :
DOS> cd OpenScientist\<kit>\obuild
DOS> setup # to setup the build environment.
DOS> DOS\build # to build the per package binaries.
DOS> DOS\build -group <driver> # to build the per package binaries
# related to a driver.
DOS> DOS\build_release # to build the binary .zip file
# in the ..\bin_obuild directory.
It is assumed that the compiler and linker commands are at hand from the shell prompt. On a Windows, then before doing a DOS\build, be sure that the commands cl.exe, link.exe, etc... are up and running (that is to say that VisualC++ is installed). We remember that on a Windows you have to do something like :
CALL "C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools"\vsvars32.bat
to setup the VisualC++ environment to work from a DOS prompt.
The main build
obuild/sh/build (or obuild\DOS\build.bat)
goes, in order, in the various packages and executes their
obuild/sh/build (or obuild\DOS\build.bat)
If something went wrong in a package, you can build the package directly from there :
sh> . ./setup.sh # to setup the build environment.
( csh> source setup.csh )
UNIX> cd ../../<package>/obuild
UNIX> ./sh/build # to build the package binaries.
UNIX> ./sh/build -group <driver> # to build the package binaries
# related to a driver.
and on a Windows :
DOS> setup # to setup the build environment.
DOS> cd ..\..\<package>\obuild
DOS> DOS\build # to build the package binaries.
DOS> DOS\build -group <driver> # to build the package binaries
# related to a driver.
For example an osc_batch kit comes with readers for various file formats. But the default build do not necessary attempt to build all of them. By default the build of an osc_batch kit build the readers for the .root and .aida files format. The reader for the CERN .hbook format needs to have the CERNLIB installed to be built. Then the build of this reader is not done by default. To trigger this build, you have to install first the CERNLIB and then have to ask to build the "group" of packages or code related to CERNLIB. This is done by issuing a :
UNIX> ./sh/build -group Zebra
DOS> DOS\build -group Zebra
(ok, ok it should be -group CERNLIB).
An important idea is that a "group" is related to code that needs a "foreign" (or external) package to be built. That is to say a package / software not coming with the OpenScientist source distribution. Which is why we need a special mechanism to build this kind of code.
There is only one group for an osc_batch kit but there is more for an osc_vis kit. The today possible groups are :
osc_batch : Zebra
osc_vis : Python, gtk, Qt, SDL, Geant3, Geant4
Before attempting the build of a group you must ensure that the corresponding "foreign" package is installed on your computer. The way that the obuild system (the build system of OpenScientist) accesses a foreign package is described in some XML .obuild file which is found under :
OpenScientist/foreign.
See next section for more.
Experience shows that good part of problems are related to the access of the "foreign" packages. That is to say packages for which the source does not come with OpenScientist (for example CERNLIB, Motif, Qt, Geant4, etc...). To customize the access to a foreign package, edit the related .obuild file found under the directory :
OpenScientist/foreign.
(For example Geant4.obuild or Python.obuild). After customization of an .obuild XML file you have to rebuild the build scripts of a package, that is to say the file under the directory :
<package>/obuild
The reconstruction of the "obuild" material of a package is done executing the obuild program from the obuild directory of the package. For example to customize the access to CERNLIB for the BatchLab Zebra driver :
UNIX> <edit ../../foreign/CERNLIB.obuild>
UNIX> cd ../../BatchLab/obuild
UNIX> ../../obuild/bin_obuild/obuild
( UNIX> chmod a+x sh/build )
UNIX> ./sh/build -group Zebra
and on a Windows to customize the access of CLHEP and Geant4 for the G4Lab pacakge :
DOS> <edit ..\..\foreign\CLHEP.obuild>
DOS> <edit ..\..\foreign\Geant4.obuild>
DOS> cd ..\..\G4Lab\obuild
DOS> ..\..\obuild\bin_obuild\obuild
DOS> DOS\build -group Geant4
See The obuild program for more on the obuild tool. In particular the obuild -shell to execute obuild at once on all the packages of a project package.
The build is done with the standalone obuild tool that comes with OpenScientist. The packages are found by using the OBUILD_PATH variable which is set in the setup of a source kit. To work on a package, you must be in its obuild directory. In it there is a this.obuild XML file describing what to build. From the obuild directory of a package, the basic commands are :
OS> <path to obuild>/obuild # to (re)generate the various scripts
# after a modification of the this.obuild
# or a related XML .obuild file.
UNIX> sh/build # to build silently.
UNIX> sh/build -v # to have a verbose mode.
UNIX> sh/build -g # to build in debug mode.
UNIX> sh/build -group <group> # to build only some specific target.
( UNIX> sh/build -v -group Zebra )
( UNIX> sh/build -v -group Python )
( UNIX> sh/build -v -g -group Qt )
and on Windows :
DOS> DOS\build
etc...
Note that you can build directly a library, dll, program named xxx with :
UNIX> sh/build_dll_xxx
UNIX> sh/build_lib_xxx
UNIX> sh/build_app_xxx
and on Windows :
DOS> DOS\build_dll_xxx
etc...
See The obuild program for more on the obuild tool.
For the batch kit (osc_batch_source-version.zip), since the code is in principle ANSI C/C++ and does not rely on "foreign" (or "external") packages, the construction should be straightforward on all platforms. The build should do in order : obuild, zlib, expat, Lib, HCL, Midnight, Minuit, Rio, HDF5, BatchLab, UseAIDA.
The Zebra driver building the BatchLabZebra plugin needed to read CERNLIB .hbook files is optional. The default build does not build it. If wanting it, you may have to customize the :
foreign/CERNLIB.obuild
file and do from the BatchLab package obuild directory :
( UNIX> obuild # if having changed the CERNLIB.obuild )
UNIX> sh/build -group Zebra
or on a Windows :
DOS> DOS\build -group Zebra
But the customization of CERNLIB.obuild may be not needed if CERNLIB is installed at its usual place
/cern/pro (and C:\cern\pro on a Windows).
On a Windows the default GUI is then Windows and then the default build need no tuning and should then be straightforward.
On a UNIX, the default build needs OpenMotif. The defaults in
foreign/Motif.obuild
assume to find OpenMotif under /usr/X11R6 for a Linux, /sw for a Mac (then OpenMotif installed with Fink) or under /usr for other UNIXes.
The build should do in order the "batch" packages and then continue with : jpeg, dvi2bitmap, freetype2, CoinGL, CoinXt (CoinWin on a Windows), HEPVis, KUIP, OnX, OnXLab, VisAIDA, OpenPAW.
All other drivers (Python, Qt) are optionals and the build of them could be done with :
UNIX> sh/build -group Python
( DOS> DOS\build -group Python )
UNIX> sh/build -group Qt
( DOS> DOS\build -group Qt )
And the customization is done in the Python.obuild, Qt.obuild files found in the foreign package. For example, a "build -group Python" from the head obuild directory will do : CoinPython and then HEPVis, OnX, OnXLab python driver (which are nothing more than the SWIG Python wrapping of CoinGL, HEPVis, OnX, OnXLab).
Experience shows that building from source is never simple. Common build problems are:
The foreign .obuild file of the foreign package is not customized for your own platform.
If you are in these quite common messy situations, contact first your system manager or some experienced people that can seat in front of the screen with you to see what is available on your computer and help you to configure the adequate foreign .obuild file.
If nothing work for you and you feel definitely alone on this planet with you computer and that you are ready to smash it on the wall, please contact the LAL OpenScientist support : we shall see what we can do. And please do not forget to specify your platorm, that is to say the kind of operating system you are using and also (important in C++ !) the compiler and its version. In case of Linux, specify the kind of distribution your are using.
You must be fully aware that OpenScientist is a generic data analysis tool and that, by principle, this kind of software have to deal with all computing domains (graphics, GUI, scripting, storage, etc...), a lot of beside software (zip, freetype, Motif, Qt, Geant4, etc...) and must run on a bunch of heterogenous platforms. In fact it is a mere miracle that we can provide something consistent at all ! Then be aware that "having problem" when building is definitely something to expect... Then first of all, before attempting a build : have a breath and KEEP COOL !
The source kits contains the CVS directories ready for an anonymous access. This permits an easy update of a package in case of a bug correction or a simple update.
The LAL resident packages can be accessed with :
CVSROOT :pserver:anonymous@cvsserver.lal.in2p3.fr:/projects/cvs
password: <empty>
co <Package>
The HEPVis package can be retrieved at FNAL by using an anonymous CVS access.
CVSROOT :pserver:hvread@cepasrv1.fnal.gov:/home/local/viscvs/cvs
password : <empty>
co HEPVis
The AIDA package can be retrieved at SLAC by using an anonymous CVS access.
CVSROOT :pserver:anoncvs@cvs.freehep.org:/cvs/aida
password : aida
co aida