This is a text help for LogService installation, extracted from the User's Manual. 



                                 Dependencies



General remarks on LogService platform dependencies

   LogService is itself written in C/C++ and for limited parts in java. LogService is
   based on CORBA and thus depends on the chosen CORBA implementation.
   Thus, we could expect LogService to be effective on any platform offering
   decent version of such compilers.

   Nevertheless, if you encounter installation difficulties don't hesitate
   to post on DIET's users mailing list: \verb+diet-usr@listes.ens-lyon.fr+
   (for the archives refer to \url{http://graal.ens-lyon.fr/DIET/mail-lists.html}).
   Note that LogService has no dependencies with DIET, but it has been developped in
   order to be used with DIET. The DIET team support the developpment of LogService.

   If you find a bug in LogService, please don't hesitate to submit a bug report on
   \url{http://graal.ens-lyon.fr/bugzilla}. If you have multiple bugs
   to report, please make multiple submissions, rather than submitting
   multiple bugs in a single report.

Hardware dependencies

   LogService is fully tested on Linux/i386 and Linux/i686 platforms. LogService is known
   to be effective on Linux/Sparc, Linux/i64, Linux/amd64, Linux/Alpha, 
   Linux/PowerPC AIX/powerPC and MacOS/PowerPC platforms.

Supported Compilers

   LogService is supported on GCC with versions ranging from 3.2.X to 4.1.X. Note 
   that due to omniORB 4 requirements towards thread-safe management of
   exception handling, compiling LogService with gcc requires at least gcc-2.96.
   LogService is supported also on XL C/C++ compiler (IBM).

Operating System dependencies

   LogService is fully tested on Linux [with varying distributions like Debian,
   Red Hat Enterprise Linux (REL-ES-3), Fedora Core (5)], on AIX (5.3) and 
   on MacOSX (Darwin 8).

Software dependencies

   CORBA is used for all communications inside the platform.
   The implementations of CORBA currently supported in LogService is omniORB 4
   which itself depends on Python.

   NB: We have noticed that some problems occur with Python 2.3: the C++ 
   code generated by idl could not be compiled. It has been patched in LogService,
   but some warnings may still appear.

   omniORB 4 itself also depends on OpenSSL in case you wish to secure 
   your LogService platform. If you want to deploy a secure LogService platform, SSL
   support is not yet implemented  in LogService, but an easy way to do so is to 
   deploy LogService over a VPN.

   In order to deploy CORBA services with omniORB, a configuration file
   and a log directory are required for a complete description of the 
   services. Their paths can be given to omniORB either at runtime 
   (through the well-known environment variables $OMNIORB_CONFIG and
   $OMNINAMES_LOGDIR), and/or at omniORB compile time (with the
   --with-omniORB-config and --with-omniNames-logdir options).


                             Compiling the platform



   LogService compilation process moved away from the traditional autotools way of
   things to a tool named cmake (mainly to benefit from cmake's built-in
   regression tests mechanism).

   Before compiling LogService itself, first install the above mentioned dependencies.
   Then untar the LogService archive and change current directory to its root 
   directory.

Obtaining and installing cmake per se

   LogService requires using cmake at least version 2.4.7. For many popular  
   distributions cmake is incorporated by default or at least apt-get (or 
   whatever your distro package installer might be) is cmake aware. Still, in
   case you need to install an up-to-date version cmake's official site 
   distributes many binary versions (alas packaged as tarballs) which are made
   available at http://www.cmake.org/HTML/Download.html.
   Optionally, you can download the sources and recompile them: this simple
   process (./bootstrap; make; make install) is described at 
   http://www.cmake.org/HTML/Install.html.

Configuring LogService's compilation: cmake quick instruction

   If you are already experienced with cmake then using it to compile LogService
   should provide no surprise. 
   LogService respects cmake's best practices e.g. by clearly separating the source
   tree from the binary tree (or compile tree), by exposing the main configuration
   optional flag variables prefixed by LOGSERVICE_ and by hiding away the technical
   variables) and by not postponing configuration difficulties (in particular
   the handling of external dependencies like libraries) to compile stage.

   Cmake classically provides two ways for setting configuration parameters in 
   order to generate the makefiles in the form of two commands ccmake and cmake
   (the first one has an extra "c" character):

   -- ccmake [options] <path-to-source> 
   in order to specify the parameters interactively through a GUI interface

   -- cmake [options] <path-to-source> [-D<var>:<type>=<value>]
   in order to define the parameters with the -D flag directly from the command line.

   In the above syntax description of both commands, <path-to-source> specifies 
   a path to the top level of the source tree (i.e. the directory where the top 
   level CMakeLists.txt file is to be encountered). Also the current working 
   directory will be used as the root of the build tree for the project (out of
   source building is generally encouraged especially when working on a CVS tree).

   Here is a short list of cmake internal parameters that are worth mentioning:
   
   -- CMAKE_BUILD_TYPE controls the type of build mode among which Debug will 
   produce binaries and libraries with the debugging information

   -- CMAKE_VERBOSE_MAKEFILE is a Boolean parameter which when set to ON will 
   generate makefiles without the .SILENT directive. This is useful for watching 
   the invoked commands and their arguments in case things go wrong.

   -- CMAKE_C[XX]_FLAGS* is a family of parameters used for the setting and the 
   customization of various C/C++ compiler options.

   -- CMAKE_INSTALL_PREFIX variable defines the location of the install directory
   (defaulted to /usr/local on un*x). This is cmake's portable equivalent of the 
   autotools configure's --prefix= option.

   Eventually, here is a short list of ccmake interface tips:

   --  when lost, look at the bottom lines of the interface which always 
   summarizes ccmake's most pertinent options (corresponding keyboard shortcuts) 
   depending on your current context

   -- hitting the "h" key will direct you ccmake embedded tutorial and a list of 
   keyboard shortcuts (as mentioned in the bottom lines, hit "e" to exit)

   -- up/down navigation among parameter items can be achieved with the up/down 
   arrows

   -- when on a parameter item, the line in inverted colors (close above the 
   bottom of the screen) contains a short description of the selected parameter 
   as well as the set of possible/recommended values

   -- toggling of boolean parameters is made with enter
   
   -- press enter to edit path variables

   -- when editing a PATH typed parameter the TAB keyboard shortcut provides an
   emacs-like (or bash-like) automatic path completion.

   -- toggling of advanced mode (press "t") reveals hidden parameters

A ccmake walk-through for the impatients

   Assume that LOGSERVICE_HOME represents a path to the top level directory of 
   LogService sources. This LogService sources directories tree can be obtained by LogService 
   users by expanding the LogService current source level distribution tarball.
   But for the developers this directories tree simply corresponds to the 
   directory GRAAL/devel/diet/diet-contrib/LogService of a cvs checkout of the 
   LogService sources hierarchy.

   Additionally, assume we created a build tree directory and cd to it (in the 
   example below we chose LOGSERVICE_HOME/build as build tree, but feel free to 
   follow your conventions):


   -- cd LOGSERVICE_HOME/build

   -- ccmake .. to enter the GUI

   -- press c (equivalent of bootstrap.sh of the autotools)

   -- toggle the desired options e.g. LOGSERVICE_BACKGROUND

   -- specify the CMAKE_INSTALL_PREFIX parameter (if you wish to install in a 
   directory different from /usr/local,

   -- press c again, for checking required dependencies check all the parameters 
   preceded with the * (star) character whose value was automatically retrieved 
   by cmake.

   -- provide the required information i.e. fill in the proper values for all 
   parameters whose value is terminated by NOT-FOUND

   -- iterate the above process of parameter checking, toggle/specification and
   configuration until all configuration information is satisfied 


   -- press g to generate the makefile 

   -- press q to exit ccmake

   -- make in order to classically launch the compilation process

   -- make install when installation is required

LogService's main configuration flags

   Here are the main configuration flags:

   -- OMNIORB4_DIR is the path to the omniORB4 installation directory (only 
   relevant when omniORB4 was not installed in /usr/local).

   -- LOGSERVICE_BACKGROUND Add the background support

   Example: cmake .. -DOMNIORB4_DIR:PATH=$HOME/local/omniORB-4.0.7



                             Compiling and installing



Summarizing the configuration choices

   Once the configuration is properly made one can check the choices made
   by looking the little summary proposed by cmake.
   This summary should look like ([...] denotes eluded portions):

   ~/LogService > ./cmake ..
   -- XXX System name Linux
   -- Configuring done
   -- Generating done
    -- Build files have been written to: /home/diet/devel/LOGSERVICE/logservice-cvs/build

   A more complete, yet technical, way of making sure is to check the content
   of the file named CMakeCache.txt (generated by cmake in the directory 
   from which cmake was invocated).
   When exchanging with the developers list it is a recommendable practice
   to join the content of this file which summarizes your options and also
   the automatic package/library detections made by cmake.

Compiling stage

   You are now done with the configuration stage (equivalent of both the
   bootstrap.sh and ./configure stage of the autotools).
   You are now back to your platform level development tools i.e. +make
   when working on Unices.
   Hence you can now proceed with the compiling process by launching make.
