Build from source

After unzipping one a :


go under the directory


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.

Main instructions

To build from source an OpenScientist kit on a UNIX, after unziping do :

    UNIX> cd OpenScientist/<kit>/obuild  
      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> . ./               # 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.

What is a "group" (or 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 :


See next section for more.

Customize the build

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 :


(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 :


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 obuild program

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                

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                

See The obuild program for more on the obuild tool.

Notes for building a osc_batch kit

For the batch kit (, 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 :


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).

Notes for building a osc_vis kit

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


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 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 :

    password: <empty>
    co <Package>

The HEPVis package can be retrieved at FNAL by using an anonymous CVS access.

    password : <empty>
    co HEPVis

The AIDA package can be retrieved at SLAC by using an anonymous CVS access.

    password : aida
    co aida