From 7987041173edc6dfb9b29780f4dbea84a256b3d1 Mon Sep 17 00:00:00 2001 From: prascle Date: Tue, 11 Oct 2005 16:20:31 +0000 Subject: [PATCH] PR: doc --- README.FIRST.txt | 15 ++++- doc/INSTALL.txt | 15 ++++- doc/SALOME_Application.txt | 130 +++++++++++++++++++++++++++++++++++++ doc/UnitTests.txt | 36 +++++++++- 4 files changed, 191 insertions(+), 5 deletions(-) create mode 100644 doc/SALOME_Application.txt diff --git a/README.FIRST.txt b/README.FIRST.txt index 03e9739b5..4e1032645 100644 --- a/README.FIRST.txt +++ b/README.FIRST.txt @@ -8,14 +8,27 @@ General information, for developpers and users 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 ---------------------------------------- diff --git a/doc/INSTALL.txt b/doc/INSTALL.txt index c08026269..79d6b7af7 100644 --- a/doc/INSTALL.txt +++ b/doc/INSTALL.txt @@ -5,6 +5,10 @@ Installation instructions, up to date for 3.0 version You'll find here generic instructions for installing the SALOME2 platform. ++-------------------------------------------+ +| **WORK in PROGRESS, INCOMPLETE DOCUMENT** | ++-------------------------------------------+ + Summary ------- @@ -274,14 +278,14 @@ STEP 5: 6. Installing the SALOME components ----------------------------------- -Installing a component is done by following the same +TInstalling a component is done by following the same instructions as given for the KERNEL, replacing KERNEL by (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 @@ -302,6 +306,13 @@ building process of the SMESH component (STEP 3). 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:: diff --git a/doc/SALOME_Application.txt b/doc/SALOME_Application.txt new file mode 100644 index 000000000..56d6295d9 --- /dev/null +++ b/doc/SALOME_Application.txt @@ -0,0 +1,130 @@ + +====================================================================== +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" + + + diff --git a/doc/UnitTests.txt b/doc/UnitTests.txt index db9bb1637..d6c4eee50 100644 --- a/doc/UnitTests.txt +++ b/doc/UnitTests.txt @@ -7,6 +7,10 @@ You will find here general information on code directories structure, 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 ========================================== @@ -77,8 +81,8 @@ GenericObj 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 @@ -116,3 +120,31 @@ SALOMEDSImpl 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. + + + + -- 2.39.2