From: prascle Date: Sat, 15 Oct 2005 10:22:58 +0000 (+0000) Subject: PR: complements on doc files X-Git-Url: http://git.salome-platform.org/gitweb/?a=commitdiff_plain;h=b69d6485a28abd1735b62b3f876021e110e1e6a2;p=modules%2Fkernel.git PR: complements on doc files --- diff --git a/README.FIRST.txt b/README.FIRST.txt index 4e1032645..4a727c643 100644 --- a/README.FIRST.txt +++ b/README.FIRST.txt @@ -26,7 +26,7 @@ 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 +.. _SALOME_Application: ./doc/SALOME_Application.html Source code structuration and Unit Tests diff --git a/doc/INSTALL.txt b/doc/INSTALL.txt index 79d6b7af7..dddcadb43 100644 --- a/doc/INSTALL.txt +++ b/doc/INSTALL.txt @@ -285,7 +285,7 @@ instructions as given for the KERNEL, replacing KERNEL by You just have to be aware of the dependencies between components: - MED depends on KERNEL -- GEOM depends on KERNE +- GEOM depends on KERNEL - SMESH depends on KERNEL, MED, GEOM - VISU depends on KERNEL, MED - SUPERV depends on KERNEL @@ -309,7 +309,7 @@ building process of the SMESH component (STEP 3). 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 +.. _SALOME_Application: ./SALOME_Application.html The following explains the general principles. diff --git a/doc/SALOME_Application.txt b/doc/SALOME_Application.txt index 56d6295d9..1133e1e62 100644 --- a/doc/SALOME_Application.txt +++ b/doc/SALOME_Application.txt @@ -13,11 +13,26 @@ 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 +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...). @@ -31,14 +46,25 @@ 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. +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 @@ -61,23 +87,23 @@ 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 -~~~~~~~~~~~~~~~~~~~~~~~~~~ +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: @@ -87,8 +113,8 @@ runAppli 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. @@ -102,18 +128,18 @@ runTests 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 diff --git a/doc/UnitTests.txt b/doc/UnitTests.txt index d6c4eee50..6b5808d19 100644 --- a/doc/UnitTests.txt +++ b/doc/UnitTests.txt @@ -18,27 +18,34 @@ the unit tests. ----------------------------------- 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 --------------------------------------------- @@ -75,7 +82,7 @@ Utils 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, @@ -125,11 +132,11 @@ SALOMEDS **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.