| **WORK in PROGRESS, INCOMPLETE DOCUMENT** |
+-------------------------------------------+
-The follwing explains how to configure your own application with your list of
+The following 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
-------------------
+Summary
+-------
+
+`1. General principles`_
+
+`2. Application Directory`_
+
+`2.1 Proposal for env.d scripts`_
+
+`2.2 User run scripts`_
+
+`2.3 SALOME internal run script`_
+
+`2.4 Other configuration files`_
+
+1. General principles
+---------------------
A SALOME application is defined by a set of modules (GEOM, SMESH, ASTER...).
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.
+There is no need to have all the modules on each computer (the minimum is
+KERNEL).
+
+There is no need of standardization or centralised information on the details
+of configuration on each computer (PATH, LD_LIBRARY_PATH, environment
+variables) provided the application modules are version - compatible. Details
+of configuration stay private to the computer, and are held by scripts on each
+computer.
+
+There is no hierarchy between the computers (for example only one master
+computer used to launch application).
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).
+password (key exchange for ssh). Account may be different on each
+computer.
-Application Directory
----------------------
+2. 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
alphanumeric order (after edition, think to remove backup files). the envd
script is used by run scripts.
-Proposal for env.d scripts
-~~~~~~~~~~~~~~~~~~~~~~~~~~
+2.1 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,
+ Sets the computer configuration not directly related to SALOME,
like useful tools, default PATH.
envProducts.sh
- sets the SALOME prerequisites.
+ Sets the SALOME prerequisites.
envSALOME.sh
- sets all the MODULE_ROOT_DIR that can be used in the SALOME application.
+ Sets all the MODULE_ROOT_DIR that can be used in the SALOME application.
-User run scripts
-~~~~~~~~~~~~~~~~
+2.2 User run scripts
+~~~~~~~~~~~~~~~~~~~~
The SALOME user can use 4 scripts:
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.
+ Launches 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.
and port number), runTests defines a new configuration for naming service
(new port number).
-SALOME internal run script
-~~~~~~~~~~~~~~~~~~~~~~~~~~
+2.3 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
+ This script is mainly used to launch containers. The first 2 arguments
+ define the hostname and port userd for naming service, the remaining
arguments define the command to execute.
-Other configuration files
-~~~~~~~~~~~~~~~~~~~~~~~~~
+2.4 Other configuration files
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SalomeApp.xml
This file is similar to the default given in $GUI_ROOT_DIR
-----------------------------------
KERNEL_SRC
+ Some README files and configuration tools for build
KERNEL_SRC/adm_local
+ Part of the configuration files
KERNEL_SRC/bin
+ Python and shell scripts used at run time.
KERNEL_SRC/doc
+ Kit for end user documentation production: public interfaces, graphic,
+ Python, CORBA. Developper documentation.
KERNEL_SRC/examples
+ To be removed.
KERNEL_SRC/idl
+ All CORBA interfaces from KERNEL are regrouped here.
KERNEL_SRC/resources
+ Configuration files for servers (examples). Icons for Graphic interface
+ (to be removed ?)
KERNEL_SRC/salome_adm
-
-KERNEL_SRC/share
+ Makefile includes and configuration files (M4 macros)
KERNEL_SRC/src
-
-KERNEL_SRC/tests
-
+ The source code (C++ and Python)
+
1.2 Directory src: C++ and Python source code
---------------------------------------------
exception system.
NamingService
- C++ and Python interfaces to name, store and retreive CORBA objects
+ C++ and Python interfaces to name, store and retrieve CORBA objects
GenericObj
A generic CORBA interface for CORBA objects, to count distributed references,
**TO BE COMPLETED**
-Unit Testing rely on cppunit package for C++ testing, and on unitest module
+Unit Testing rely on cppunit package for C++ testing, and on unittest 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.
+tests are compiled.
Unit Tests sources are in directories Test under the src/directories
containing the classes to test.
