Using inlib

Once the source code is on your disk, have in your code

    #include <inlib/some_file>
    <use things found in some_file>

for example :

    #include <inlib/histos/h1d>
    #include <inlib/random>
    inlib::random::gauss rg(1,2);
    inlib::histo::h1d h("Gauss",100,-5,5);
    for(int count=0;count<10000;count++) {

The only thing to do next is to arrange to have in your build system (a GNUmakefile, Xcode, VisualStudio, Eclipse, scons, your bash script, etc...) the :

    -I<path to inlib>
 or on a Windows build system :
    /I<path to inlib>

to find the used inlib files. Then rebuild your application and run ! Simple.

Using exlib (and ourex packages, or not)

The usage of exlib is quite similar. For example to use exlib/jpeg :

    #include <exlib/jpeg>
    if(!exlib::jpeg::is("my_file.jpg")) {
      std::cout << " file is not a jpeg file." << std::endl;

In your build system you need to have :

    -I<path to exlib> -I<path to inlib>

But you have also to attach an installation of the external package (here jpeg). In order to ease the "build and install" of our apps that use exlib and to be sure to have the same comportement of the apps on various platforms, the exlib headers give priority to external packages coming under the "ourex" directory of an app distribution. If you don't want to use the ourex distribution and attach a jpeg already installed on your system, you have to set the cpp macro

 for example for jpeg :

and then to declare to your build system (here for a UNIX like one) :

    -I<path to the jpeg headers>
 and to link with the external package library :
    -L<path to the jpeg lib dir> -l<lib of the external>

Then rebuild your application and run. Quite simple too.

If you want to use the ourex distribution of an external package, then do not set the EXLIB_USE_NATIVE_<EXT> cpp macro, and declare to your build system :

    -I<ourex path to the external package headers>

and all the source files of the ourex external package distribution in order to compile and link them to your application.

Some of the EXLIB_NATIVE_<EXT> macros are :


with each one corresponding to an ourex package.


Note that there is a bit of philosphy here. Force to state that external packages are the number one source of problem with users when "building for installing" or even with more advanced developers when "building for developing", if having to coope with all the "build systems" around. We have decided to get rid of this problem by embarquing stable versions of common externals, and right now this way of doing permits us to keep the portability of our apps on a large amount of heterogenous platforms.