(to be completed)
-Most important SALOME modules (KERNEL, GUI, MED) exposes their configuration
-in a dedicated CMake file.
+Most important SALOME modules (KERNEL, GUI, MED) expose their configuration in a dedicated CMake file.
Following the CMake tutorial (http://www.cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file) some
important module install \*Config.cmake files facilitating the configuration of other dependent modules. When writing such
RUNTIME DESTINATION "${INSTALL_BIN_DIR}")
+
+possibility to have a minimal specification on the prerequisites (technically one just need to set the _ROOT_DIR variables for the packages that were never found before), and to get "for free" what was already found in a dependent module
Package detection mechanism
===========================
-Philosophy and priority order
------------------------------
+Philosophy
+----------
The philosophy of the SALOME package detection is to rely as
much as possible on the standard CMake modules.
It is assumed those modules will get better and better with newer releases of CMake
and doing so ensures future compatibility with newer versions of CMake.
+Root dir variables and priority order
+-------------------------------------
+
The detection is however guided through a variable of the form XYZ_ROOT_DIR which
gives the root directory of an installation of the package. For example, to indicate
that we wish to use the Python installed in our home directory, one sets PYTHON_ROOT_DIR to
XYZ_ROOT_DIR
-where <XYZ> is the upper case name of the standard CMake module. For example, the
-detection of Qt4 is guided by setting QT4_ROOT_DIR.
+where <XYZ> is (*exactly*) the upper case name of the standard CMake module. For example, the
+detection of Qt4 is guided by setting QT4_ROOT_DIR. The variables \*_ROOT_DIR are only there to guide the process, not to force it. Typically under Linux, one would never set PTHREAD_ROOT_DIR, thus leaving the logic find the system installation.
The order of priority for the detection of a package is (from high to low priority):
* as first argument the name of the package (here CppUnit),
* as second argument, the name of a (path) variable set when the package is found properly,
- * and as third argument, the number of levels this variable should be browsed up to reach the root directory of the package installation.
+ * as third argument, the number of levels this variable should be browsed up to reach the root directory of the package installation.
+ * as optional fourth (and plus) argument: a list of components (if needed - e.g. for Qt4, we only load a subset of components)
* in the example above, we look for the package CppUnit (note that this is case-sensitive). There is already a standard CMake module to detect CppUnit, which sets the CMake variable CPPUNIT_INCLUDE_DIRS to the (list of) directories to include when compiling with CppUnit. Going one level up from the include directory (typically /usr/include) gives the root directory of the installation (/usr)
* the reference variable may be a list, only its first element is then considered.
The core of the SALOME detection logic is located in the macro
SALOME_FIND_PACKAGE_AND_DETECT_CONFLICTS() implemented in KERNEL/salome_adm/cmake_files/SalomeMacros.cmake.
+All the logic is thus concentrated in one (hopefully well documented) macro. This means: one place to fix if there is a bug, and better, one place to amend if we ever want to define a new behaviour (for example if we want to change the order of priorities between CONFIG and MODULE mode). The end user (someone developing in SALOME) just needs to call it. It is the responsability of the core SALOME developpers to understand and maintain this macro.
+
The reader is invited to read the have the code at hand when reading the following.
The macro signature is
+
+
+
