The Installation Wizard can be launched in two modes: GUI and batch.
The root directory of the Installation Wizard contains Python
script runInstall. To run the Installation Wizard just type
- runInstall in the terminal window:
+ ./runInstall in the terminal window:
- [ python ] runInstall [<options>]
+ [ python ] ./runInstall [<options>]
Without any option this script will launch the SALOME Installation
Wizard in the default mode (GUI) with the default installation
source salome.csh
where <KERNEL_ROOT_DIR> is KERNEL binaries directory, e.g.
- KERNEL_4.1.4 for the 4.1.4 version.
+ KERNEL_6.4.0 for the 6.4.0 version.
2.2. Launching of SALOME
After you set environment you can start SALOME. Go to the KERNEL
- module's binaries directory (KERNEL_4.1.4/bin/salome for the version
- 4.1.4) by using of 'cd' command and then type:
+ module's binaries directory (KERNEL_6.4.0/bin/salome for the version
+ 6.4.0) by using of 'cd' command and then type:
runSalome [<parameters>]
<parameter name="xterm" value="no"/>
<parameter name="portkill" value="no"/>
<parameter name="killall" value="no"/>
- <parameter name="modules" value="GEOM,SMESH,VISU,SUPERV,MED,COMPONENT"/>
+ <parameter name="modules" value="GEOM,SMESH,VISU,MED,YACS"/>
<parameter name="embedded" value="SalomeAppEngine"/>
<parameter name="standalone" value="study,pyContainer,cppContainer,registry,moduleCatalog"/>
</section>
Some parameters described in configuration file can be overridden by
using of corresponding command-line options for runSalome script:
- --gui
- Launch GUI desktop
- --logger
- Use logger server
- --xterm
- Start each server in its own xterm console window
- --portkill
- Kill SALOME, running on the current port
- --killall
- Kill SALOME, running on all ports
- --modules=<module>,<module>,...,<module>
- Use module(s), possible values are GEOM,SMESH,VISU,MED,SUPERV,etc.
- --embedded=<server>,<server>,...<server>
- Start specified server/container(s) embedded in SALOME Session server
- (i.e. running in the same process), possible values are registry,
- study, moduleCatalog, cppContainer, registry
- --standalone=<server>,<server>,...<server>
- Start standalone server/container(s), possible values are registry,
- study, registry, moduleCatalog, cppContainer, pyContainer, supervContainer.
+ -t, --terminal
+ Launch without GUI (in the terminal mode).
+ -g, --gui
+ Launch in GUI mode [default].
+ -d <1/0>, --show-desktop=<1/0>
+ 1 to activate GUI desktop [default], 0 to not activate
+ GUI desktop (Session_Server starts, but GUI is not
+ shown). Ignored in the terminal mode.
+ -o, --hide-desktop
+ Do not activate GUI desktop (Session_Server starts,
+ but GUI is not shown). The same as --show-desktop=0.
+ -b, --batch
+ Launch in Batch Mode. (Without GUI on batch machine)
+ -l, --logger
+ Redirect messages to the CORBA collector.
+ -f <log-file>, --log-file=<log-file>
+ Redirect messages to the <log-file>
+ -u <script1,script2,...>, --execute=<script1,script2,...>
+ Python script(s) to be imported. Python scripts are
+ imported in the order of their appearance. In GUI mode
+ python scripts are imported in the embedded python
+ interpreter of current study, otherwise in an external
+ python interpreter
+ -r <file>, --resources=<file>
+ Parse application settings from the <file> instead of
+ default $(HOME)/.SalomeApprc.$(version)
+ -x, --xterm
+ Launch each SALOME server in own xterm console
+ -m <module1,module2,...>, --modules=<module1,module2,...>
+ SALOME modules list (where <module1>, <module2> are
+ the names of SALOME modules which should be available
+ in the SALOME session)
+ -e <server1,server2,...>, --embedded=<server1,server2,...>
+ CORBA servers to be launched in the Session embedded
+ mode. Valid values for <serverN>: registry, study,
+ moduleCatalog, cppContainer, SalomeAppEngine [by
+ default the value from the configuration files is
+ used]
+ -s <server1,server2,...>, --standalone=<server1,server2,...>
+ CORBA servers to be launched in the standalone mode
+ (as separate processes). Valid values for <serverN>:
+ registry, study, moduleCatalog, cppContainer,
+ pyContainer, supervContainer [by default the value
+ from the configuration files is used]
+ -p, --portkill
+ Kill SALOME with the current port
+ -k, --killall
+ Kill all running SALOME sessions
+ -i <N>, --interp=<N>
+ The number of additional external python interpreters
+ to run. Each additional python interpreter is run in
+ separate xterm session with properly set SALOME
+ environment
+ -z <1/0>, --splash=<1/0>
+ 1 to display splash screen [default], 0 to disable
+ splash screen. This option is ignored in the terminal
+ mode. It is also ignored if --show-desktop=0 option is
+ used.
+ -c <1/0>, --catch-exceptions=<1/0>
+ 1 (yes,true,on,ok) to enable centralized exception
+ handling [default], 0 (no,false,off,cancel) to disable
+ centralized exception handling.
+ --print-port
+ Print free port and exit
+ --nosave-config
+ Do not save current configuration
+ ${HOME}/.omniORB_last.cfg
+ --pinter
+ Launch with interactive python console.
+ --ns-port-log=<ns_port_log_file>
+ Print Naming Service Port into a user file.
+ --gdb-session
+ Launch session with gdb
+ --version
+ Show program's version number and exit
Additional launch settings are given in other sections, which refer to certain
modules. For example, SMESH plugins which should be used in the SALOME launch
import salome_test
When running, the script loads different modules (Geometry, Mesh, Med,
- Post-Pro and Supervisor) and tests various functionalities of these
+ Post-Pro) and tests various functionalities of these
modules. You can watch the script execution progress in the embedded
python console window.
products, required for the platform and SALOME modules sources.
Then follow the scenario described below.
In this scenario it is supposed that you have installed SALOME
- modules sources in the /home/salome directory. The name of each module
+ modules sources in the /home/user/salome directory. The name of each module
sources directory depends on the version of the platform, for example,
- KERNEL_SRC_4.1.4 for KERNEL module of SALOME version 4.1.4.
+ KERNEL_SRC_6.4.0 for KERNEL module of SALOME version 6.4.0.
Compilation and installation should be performed according to
the dependencies between modules:
* MED -> KERNEL, GUI
* SMESH -> KERNEL, GUI, GEOM, MED
* VISU -> KERNEL, GUI, MED
- * SUPERV -> KERNEL, GUI
+ * YACS -> KERNEL, GUI
SMESH plugins:
- * NETGENPLUGIN -> KERNEL, GUI, SMESH
- * GHS3DPLUGIN -> KERNEL, GUI, SMESH
- * GHS3DPRLPLUGIN -> KERNEL, GUI, SMESH
- * HexoticPLUGIN -> KERNEL, GUI, SMESH
- * BLSURFPLUGIN -> KERNEL, GUI, SMESH
+ * NETGENPLUGIN -> KERNEL, GUI, MED, GEOM, SMESH
+ * GHS3DPLUGIN -> KERNEL, GUI, MED, GEOM, SMESH
+ * GHS3DPRLPLUGIN -> KERNEL, GUI, MED, GEOM, SMESH
+ * HexoticPLUGIN -> KERNEL, GUI, MED, GEOM, SMESH
+ * BLSURFPLUGIN -> KERNEL, GUI, MED, GEOM, SMESH
Sample modules:
* PYCALCULATOR -> KERNEL, MED
* CALCULATOR -> KERNEL, MED
* HELLO -> KERNEL, GUI
- * PYHELLO -> KERNEL
+ * PYHELLO -> KERNEL, GUI
* LIGHT -> KERNEL, GUI
+ * PYLIGHT -> KERNEL, GUI
* RANDOMIZER -> KERNEL, GUI
- * SIERPINSKY -> KERNEL, GUI, VISU, RANDOMIZER
+ * SIERPINSKY -> KERNEL, GUI, MED, VISU, RANDOMIZER
Note: SMESH plugins and sample modules are optional. You may skip
compiling them if you do not plan to use NETGEN and/or GHS3D meshing
algorithms and do not want to build samples.
+ Note: Meshing plug-ins BLSURFPLUGIN, HexoticPLUGIN and
+ GHS3DPRLPLUGIN require commercial license for the Distene
+ meshers in runtime mode. Moreover, BLSURFPLUGIN requires
+ blsurf product at the compilation time. Without it, the
+ BLSURFPLUGIN meshing plugin compilation will fail. Refer
+ to http://www.distene.com/ for more details.
+
In general, each module (except for KERNEL and GUI, of course) is
optional for SALOME. If you do not need a certain module, just do not
compile or install it. But remember that some modules require others
To build KERNEL module:
- - go to installation root directory (/home/salome in this example):
+ - go to installation root directory (/home/user/salome in this example):
- cd /home/salome
+ cd /home/user/salome
- to set environment variables use bash or csh script, depending on
your shell:
- create a configuration script by typing
- ../KERNEL_SRC_4.1.4/build_configure
+ ../KERNEL_SRC_6.4.0/build_configure
- run configure script which will check the environment and create
Makefile files:
- ../KERNEL_SRC_4.1.4/configure --prefix=/home/salome/KERNEL_install
+ ../KERNEL_SRC_6.4.0/configure --prefix=/home/user/salome/KERNEL-6.4.0
Note, that --prefix option defines the directory where you want to
install KERNEL module after 'make install' procedure. configure script
You can learn more about the configure of any modules by using --help (-h)
parameter.
- - build and (optionally) install KERNEL module:
+ - build and install KERNEL module:
make
make install
After you have completed this scenario, KERNEL module is built and
- installed into /home/salome/KERNEL_install directory.
+ installed into /home/user/salome/KERNEL-6.4.0 directory.
- modify your environment scripts:
* for bash:
- export KERNEL_ROOT_DIR=/home/salome/KERNEL_install
- or
- export KERNEL_ROOT_DIR=/home/salome/KERNEL_build
- (if make install step was not performed).
+ export KERNEL_ROOT_DIR=/home/user/salome/KERNEL-6.4.0
* for csh:
- setenv KERNEL_ROOT_DIR /home/salome/KERNEL_install
- or
- setenv KERNEL_ROOT_DIR /home/salome/KERNEL_build
- (if make install step was not performed).
+ setenv KERNEL_ROOT_DIR /home/user/salome/KERNEL-6.4.0
- then repeat this scenario for other modules you want to build taking
into account the dependencies between modules (see dependencies table
* for bash:
- export MODULE_ROOT_DIR=/home/salome/<MODULE_distribution>
+ export MODULE_ROOT_DIR=/home/user/salome/<MODULE_distribution>
* for csh:
- setenv MODULE_ROOT_DIR /home/salome/<MODULE_distribution>
+ setenv MODULE_ROOT_DIR /home/user/salome/<MODULE_distribution>
- where <MODULE_distribution> is a MODULE_build or MODULE_install (see above).
+ where <MODULE_distribution> is a MODULE-6.4.0 (see above).
4.2. Automatic build procedure: build.csh and build.sh scripts
./build.csh
- By default, build.csh only compiles the modules but does not install them,
- i.e. does not perform 'make install' step.
- To do this, use -i option or -p <prefix> where <prefix> is the
+ By default, build.csh builds and installs all SALOME
+ modules. All modules are installed to the INSTALL subfolder
+ of the current directory. If you need to change the installation
+ directory, you can use -p <prefix> option where <prefix> is the
directory SALOME modules should be installed to.
- If you want to build only some SALOME modules, just pass them as
- parameters, e.g.:
+ If you want to build only some subset of SALOME modules,
+ just pass them as parameters, e.g.:
- ./build.csh -i KERNEL MED GEOM
+ ./build.csh -p /home/user/salome KERNEL MED GEOM
The script also provides other options which specify compiling and
installation parameters. You can learn about these options by using
./build.csh -h
When you run build.csh for the first time it is not necessary to pass
- -b, -c parameters. The script detects if build procedure has not yet
+ -b or -c parameters. The script detects if build procedure has not yet
been performed and in this case runs build_configure, configure scripts
automatically.
Note: use -d option carefully because in this case the script removes
the existing (previously installed) SALOME modules.
- Note: please, take into your account that 'make install' step is
- obligatory for the KERNEL module. Build directory of KERNEL
- can not be indicated as KERNEL_ROOT_DIR. This is an exception
- for the SALOME modules. So you should use either option -i
- or -p of build.sch script when building KERNEL module.
-
Note: build.(c)sh scripts do not modify the environment files
(env_products.csh, etc). You should do it by yourself.
