This document corresponds to SALOME2 3.1. (alpha version)
++-------------------------------------------+
+| **WORK in PROGRESS, INCOMPLETE DOCUMENT** |
++-------------------------------------------+
+
How to install SALOME
---------------------
See INSTALL_ for general information on required configuration and
-prerequisites, compilation procedure, setting environment, first launch.
+prerequisites, compilation procedure, setting environment principles.
.. _INSTALL: ./doc/INSTALL.html
+How to run SALOME on one or more computers, SALOME Application concept
+----------------------------------------------------------------------
+
+See SALOME_Application_ to define your own configuration of SALOME and run it
+on one or several computers. This is the recommended way of configuration.
+
+../SALOME_Application: ./doc/SALOME_Application.html
+
+
Source code structuration and Unit Tests
----------------------------------------
You'll find here generic instructions for installing the SALOME2 platform.
++-------------------------------------------+
+| **WORK in PROGRESS, INCOMPLETE DOCUMENT** |
++-------------------------------------------+
+
Summary
-------
6. Installing the SALOME components
-----------------------------------
-Installing a component <COMPONENT> is done by following the same
+TInstalling a component <COMPONENT> is done by following the same
instructions as given for the KERNEL, replacing KERNEL by
<COMPONENT> (build_configure, configure, make, make install).
You just have to be aware of the dependencies between components:
- MED depends on KERNEL
-- GEOM depends on KERNEL
+- GEOM depends on KERNE
- SMESH depends on KERNEL, MED, GEOM
- VISU depends on KERNEL, MED
- SUPERV depends on KERNEL
7. Runtime
----------
+See SALOME_Application_ to define your own configuration of SALOME and run it
+on one or several computers. This is the recommended way of configuration.
+
+../SALOME_Application: ./SALOME_Application.html
+
+The following explains the general principles.
+
To run the SALOME platform, the procedure is:
- set the shell environment to get acces to third-party softwares::
--- /dev/null
+
+======================================================================
+SALOME Application Concept. Configuration for one or more computers
+======================================================================
+
+*html version of this document is produced with docutils*::
+
+ rest2html < doc.txt > doc.html
+
+This document corresponds to SALOME2 3.1. (alpha version)
+
++-------------------------------------------+
+| **WORK in PROGRESS, INCOMPLETE DOCUMENT** |
++-------------------------------------------+
+
+The follwing explains how to configure your own application with your list of
+modules, how to define and run this application on one or more computers.
+
+General principles
+------------------
+
+A SALOME application is defined by a set of modules (GEOM, SMESH, ASTER...).
+
+A SALOME User can define several SALOME Applications. These applications are
+runnable from the same user account. These applications may share the same
+KERNEL and modules. Thus, the application configuration is independant of
+KERNEL and must not be put in KERNEL_ROOT_DIR.
+
+Furthermore, prerequisites may not be the same on all the applications.
+
+A SALOME Session can run on a several computers.
+
+Binary modules and prerequisites are installed on the different computers.
+There is no need to have all the modules on each computer.
+
+The SALOME user has an account on all the computers. Access between
+account@computer is via rsh or ssh and must be configured for use without
+password (key exchange for ssh).
+
+Application Directory
+---------------------
+
+The script createAppli.sh in ${KERNEL_ROOT_DIR}/bin/salome creates an
+application directory with the given path in parameter. ${APPLI} is a path
+relative to ${HOME}.
+
+The directory is only a skeleton, the user has to edit several files to
+configure his own application.
+
+Directory ${APPLI} must be created on each computer of the application.
+The easiest way is to use the same relative path (to ${HOME}) on each computer.
+(Sometimes it is not possible to use the same path everywhere, for instance
+when ${HOME} is shared with NFS, so it is possible to define different path
+following the computers).
+
+The ${APPLI} directory contains scripts for environment and runs. Environment
+scripts must be configured (by the user) on each computer. All the environment
+scripts are in the ${APPLI}/env.d directory.
+
+The script ${APPLI}/envd sources **all** the files in ${APPLI}/env.d in
+alphanumeric order (after edition, think to remove backup files). the envd
+script is used by run scripts.
+
+Proposal for env.d scripts
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+Each user can define his own configuration for these scripts, following the
+above rules. The following is only a proposal.
+
+atFirst.sh
+ sets the computer configuration not directly related to SALOME,
+ like useful tools, default PATH.
+
+envProducts.sh
+ sets the SALOME prerequisites.
+
+envSALOME.sh
+ sets all the MODULE_ROOT_DIR that can be used in the SALOME application.
+
+User run scripts
+~~~~~~~~~~~~~~~~
+
+The SALOME user can use 4 scripts:
+
+runAppli
+ Launches a SALOME Session
+ (similar to ${KERNEL_ROOT_DIR}/bin/salome/runSalome but with a different
+ name to avoid confusions).
+
+runSession
+ launch a shell script in the SALOME application environment, with access to
+ the current SALOME session (naming service), if any.
+ Without arguments, the script is interactive. With arguments, the script
+ executes the command in the SALOME application environment.
+
+runConsole
+ Gives a python console connected to the current SALOME Session.
+ It is also possible to use runSession, then python.
+
+runTests
+ Similar to runSession, used for unit testing. runSession tries to use an
+ already existing naming service definition from a running session (hostname
+ and port number), runTests defines a new configuration for naming service
+ (new port number).
+
+SALOME internal run script
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+For remote calls, SALOME uses one script.
+
+runRemote.sh
+ this script is mainly used to launch containers. The first 2 arguments
+ define the hostname and port userd for naming service, the reamaining
+ arguments define the command to execute.
+
+Other configuration files
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+SalomeApp.xml
+ This file is similar to the default given in $GUI_ROOT_DIR
+
+CatalogRessources.xml
+ This files describes all the computer the application can use. The given
+ example is minimal and suppose ${APPLI} is the same relative path
+ to ${HOME}, on all the computers. A different directory can be set on a
+ particular computer with a line::
+
+ appliPath="my/specific/path/on/this/computer"
+
+
+
unit tests associated to the different kind of classes, and how to run
the unit tests.
++-------------------------------------------+
+| **WORK in PROGRESS, INCOMPLETE DOCUMENT** |
++-------------------------------------------+
+
1. SALOME KERNEL source code structuration
==========================================
A generic CORBA interface for CORBA objects, to count distributed references,
and to allow destruction by client.
-1.2.3 Miscelaneous CORBA servers
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+1.2.3 Miscellaneous CORBA servers
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Registry
SALOMEDS
+2. Tools and principles used for Unit testing
+=============================================
+
+**TO BE COMPLETED**
+
+Unit Testing rely on cppunit package for C++ testing, and on unitest module
+for Python. See these products for general principles of unit testing.
+
+The cppunit package is optional. When the prerequisite is detected, the unit
+test are compiled.
+
+Unit Tests sources are in directories Test under the src/directories
+containing the classes to test.
+
+Test are ordered following the order of directories given above.
+
+Tests can be run as a whole, or for a particular directory. In this case, only
+a partial test is run (the classes to test, and the classes used, i.e. the
+preceding test directories).
+
+
+Today, only some tests are written as an example. There are not yet python
+scripts in KERNEL_SRC, but it's a matter of days, there are working scripts
+to test LifeCycleCORBA_SWIG interface.
+
+
+
+
