Commit 71925f74 authored by Genial-O's avatar Genial-O
Browse files

misc: merge release 21.0.0

parents 0fa89618 b153deb3
Pipeline #177805 passed with stages
in 4 minutes and 57 seconds
......@@ -7,7 +7,7 @@ commit_msg_help = """
Required commit message:
type(scope): description
- type: enh, feat, fix, refactor
- scope: build, ci, core, doc, graphics, io, physics, test, ui, vision
- scope: build, ci, doc, test, ui
or
type: description
- type: merge, misc, style
......@@ -15,7 +15,7 @@ or
with open(commit_msg_path) as commit_msg_file:
commit_msg_content = commit_msg_file.readline()
message_regex = r'(?:(?P<scoped_type>enh|feat|fix|refactor)\((?P<scope>build|ci|core|doc|graphics|io|physics|test|ui|vision)\)|(?P<unscoped_type>merge|misc|style)): (?P<subject>[a-z].*?(?:\b|[\]\)\'\"\`])$)'
message_regex = r'(?:(?P<scoped_type>enh|feat|fix|refactor)\((?P<scope>build|ci|doc|test|ui)\)|(?P<unscoped_type>merge|misc|style)): (?P<subject>[a-z].*?(?:\b|[\]\)\'\"\`])$)'
if not re.match(message_regex, commit_msg_content):
sys.stderr.write("\n'" + commit_msg_content.strip() + "' message doesn't follow commit rules.\n")
......
stages:
- sheldon
- lint
- build
- deploy
sheldon-mr:
image: ${DOCKER_ENVDEV_MINT19}
stage: sheldon
script:
- export ORIG_BRANCH_COMMIT_SHA=$(git merge-base dev origin/${CI_COMMIT_REF_NAME})
- git clone --depth 1 https://gitlab-ci-token:${CI_JOB_TOKEN}@git.ircad.fr/Sight/sight-git.git
# Execute sheldon, on all commits from the merge request
- sight-git/hooks/sheldon ${ORIG_BRANCH_COMMIT_SHA}..${CI_COMMIT_SHA}
sheldon:
image: ${DOCKER_ENVDEV_MINT19}
stage: sheldon
script:
- git clone --depth 1 https://gitlab-ci-token:${CI_JOB_TOKEN}@git.ircad.fr/Sight/sight-git.git
- sight-git/hooks/sheldon HEAD^ HEAD
except:
- dev
- master
rst-lint:
image: python:alpine
stage: lint
......
This diff is collapsed.
......@@ -7,6 +7,13 @@ Documentation
The code must be documented with **Doxygen**, an automated tool to generate documentation.
.. rule:: Comment the code
**Doxygen** mainly generates documentation for the code structure. It also is crucial to comment the code where it
is necessary. Please refer to this excellent
`StackOverflow article <https://stackoverflow.blog/2021/07/05/best-practices-for-writing-code-comments/>`_. Each
rule in this article has to be followed.
.. rule:: Location of the documentation
Every documentation that can be useful to a user must be placed inside the header files. Thus a user of a module can
......@@ -109,7 +116,7 @@ Example 3 : Function documentation
/**
* ...
* @section Signals Signals
* - \b signal2(::fwData::Mesh::sptr) : Emitted when the mesh has changed.
* - \b signal2(sight::data::Mesh::sptr) : Emitted when the mesh has changed.
* - \b signal1(std::int64_t) : Emitted when ...
*
* @section Slots Slots
......@@ -117,8 +124,9 @@ Example 3 : Function documentation
*/
Last the xml configuration of the service must be described into a dedicated section.
It should indicate first the input, input/outputs and outputs in three subsections. The type and the name of the data should appear along with a short description.
A fourth subsection describes the rest of the parameters, and tells if it they are optional or not.
It should indicate first the input, input/outputs and outputs in three subsections. The type and the name of the
data should appear along with a short description.
A fourth subsection describes the rest of the parameters, and tells if it they are optional or not.
.. code-block:: cpp
......@@ -137,12 +145,12 @@ Example 3 : Function documentation
</service>
@endcode
* @subsection Input Input
* - \b data1 [::fwMedData::ModelSeries]: blablabla.
* - \b data1 [sight::data::ModelSeries]: blablabla.
* @subsection In-Out In-Out
* - \b data2 [::fwData::Mesh]: blablabla.
* - \b data2 [sight::data::Mesh]: blablabla.
* @subsection Output Output
* - \b data3 [::fwData::Image]: blablabla.
* - \b data4 [::fwData::Image]: blablabla.
* - \b data3 [sight::data::Image]: blablabla.
* - \b data4 [sight::data::Image]: blablabla.
* @subsection Configuration Configuration
* - \b option1 : first option.
* - \b option2(optional) : second option.
......
......@@ -3,13 +3,14 @@ XML coding
.. rule :: uid name
``uid`` should have a semantic name. They must be written in lower camel case. Don't prefix the uid by `UID` (like `imageUID`). Moreover, avoid ``uid`` like ``myXXXXX`` or ``customXXXXX``.
``uid`` should have a semantic name. They must be written in lower camel case. Don't prefix the uid by `UID` (like `imageUID`).
Moreover, avoid ``uid`` like ``myXXXXX`` or ``customXXXXX``.
.. code-block :: xml
<object uid="image" type="::fwData::Image" />
<object uid="image" type="sight::data::Image" />
<service uid="imageReader" type="::ioVTK::SImageReader">
<service uid="imageReader" type="sight::io::vtk::SImageReader">
<inout key="image" uid="image" />
</service>
......@@ -45,7 +46,7 @@ Configuration
This config opens a window containing the editors managing the ModelSeries: show/hide reconstructions, change the color, ...
Example:
<service uid="..." type="::fwServices::SConfigController">
<service uid="..." type="sight::service::SConfigController">
<appConfig id="ModelSeriesManagerWindow" />
<inout key="modelSeries" uid="..." />
<parameter replace="ICON_PATH" by="my/icon/path.ico" />
......@@ -58,7 +59,7 @@ Configuration
- ICON_PATH (mandatory): window icon
- WINDOW_TITLE(optional): window title
-->
<extension implements="::fwServices::registry::AppConfig">
<extension implements="sight::service::extension::AppConfig">
<!-- ... -->
</extension>
......@@ -93,7 +94,7 @@ Configuration
.. code-block :: xml
<service uid="cfgNegato1" type="::fwServices::SConfigController">
<service uid="cfgNegato1" type="sight::service::SConfigController">
<appConfig id="3DNegatoWithAcq" />
<inout key="imageComposite" uid="${imageComposite}" />
<inout key="modelSeries" uid="${modelSeries}" />
......@@ -114,16 +115,16 @@ Configuration
.. code-block :: xml
<object uid="seriesDB" type="::fwMedData::SeriesDB" src="ref" />
<object uid="loadingSeriesDB" type="::fwMedData::SeriesDB" src="ref" />
<object uid="imageRef" type="::fwData::Image" src="ref" />
<object uid="imageSrc" type="::fwData::Image" src="ref" />
<object uid="seriesDB" type="sight::data::SeriesDB" src="ref" />
<object uid="loadingSeriesDB" type="sight::data::SeriesDB" src="ref" />
<object uid="imageRef" type="sight::data::Image" src="ref" />
<object uid="imageSrc" type="sight::data::Image" src="ref" />
<object uid="newSeriesDB" type="::fwMedData::SeriesDB" />
<object uid="selections" type="::fwData::Vector" />
<object uid="newSeriesDB" type="sight::data::SeriesDB" />
<object uid="selections" type="sight::data::Vector" />
<object uid="currentActivity" type="::fwMedData::ActivitySeries" src="deferred" />
<object uid="computedImage" type="::fwData::Image" src="deferred" />
<object uid="currentActivity" type="sight::data::ActivitySeries" src="deferred" />
<object uid="computedImage" type="sight::data::Image" src="deferred" />
.. rule :: Comment renderers
......@@ -133,12 +134,12 @@ Configuration
<!-- ************************************************ begin 3Dscene ************************************************ -->
<service uid="3Dscene" type="::fwRenderVTK::SRender">
<service uid="3Dscene" type="sight::viz::scene3d::SRender">
<!-- ... -->
</service>
<service uid="adaptor1" type="::visuVTKAdaptor::SMesh" />
<service uid="adaptor2" type="::visuVTKAdaptor::SMesh" />
<service uid="adaptor1" type="sight::module::viz::scene3d::SMesh" />
<service uid="adaptor2" type="sight::module::viz::scene3d::SMesh" />
The starts of these adaptors must be preceded by a comment with the scene name
......@@ -159,15 +160,15 @@ Example
<!-- ************************************************** begin data ************************************************* -->
<object uid="image" type="::fwData::Image" />
<object uid="image" type="sight::data::Image" />
<!-- *************************************************** begin GUI ************************************************* -->
<service uid="frame" type="::gui::frame::SDefaultFrame">
<service uid="frame" type="sight::module::ui::base::SFrame">
<gui>
<frame>
<name>Application</name>
<icon>Application-@PROJECT_VERSION@/tuto.ico</icon>
<icon>Application/tuto.ico</icon>
</frame>
</gui>
<registry>
......@@ -175,9 +176,9 @@ Example
</registry>
</service>
<service uid="mainView" type="::gui::view::SDefaultView">
<service uid="mainView" type="sight::module::ui::base::SView">
<gui>
<layout type="::fwGui::CardinalLayoutManager">
<layout type="sight:ui::base::CardinalLayoutManager">
<view align="center" />
<view align="bottom" minWidth="400" minHeight="30" />
<view align="bottom" minWidth="40" minHeight="30" />
......@@ -192,7 +193,7 @@ Example
<!-- ************************************************ begin actions ************************************************ -->
<service uid="actionOpenImage" type="::gui::action::SSlotCaller">
<service uid="actionOpenImage" type="sight::module::ui::base::com::SSlotCaller">
<slots>
<slot>imageReader/update</slot>
</slots>
......@@ -200,23 +201,23 @@ Example
<!-- ******************************************** begin readers/writers ******************************************** -->
<service uid="imageReader" type="::uiIO::editor::SIOSelector">
<service uid="imageReader" type="::sight::module::ui::base::io::SSelector">
<inout key="data" uid="imageUID" />
<type mode="reader" />
</service>
<!-- *********************************************** begin editors ************************************************* -->
<service uid="sliceEditor" type="::uiImageQt::SliceIndexPositionEditor" autoConnect="yes">
<service uid="sliceEditor" type="::sight::module::ui::qt::image::SliceIndexPositionEditor" autoConnect="yes">
<inout key="image" uid="imageUID" />
<sliceIndex>axial</sliceIndex>
</service>
<service uid="snapshotEditor" type="::uiVisuQt::SnapshotEditor" />
<service uid="snapshotEditor" type="::sight::module::ui::qt::viz::SnapshotEditor" />
<!-- ************************************************ begin 3Dscene ************************************************ -->
<service uid="3Dscene" type="::fwRenderVTK::SRender">
<service uid="3Dscene" type="sight::viz::scene3d::SRender">
<scene>
<picker id="myPicker" vtkclass="fwVtkCellPicker" />
<renderer id="default" background="0.0" />
......@@ -226,12 +227,12 @@ Example
</scene>
</service>
<service uid="imageAdaptor" type="::visuVTKAdaptor::SNegatoMPR" autoConnect="yes">
<service uid="imageAdaptor" type="sight::module::viz::scene3d::SNegatoMPR" autoConnect="yes">
<inout key="image" uid="imageUID" />
<config renderer="default" picker="myPicker" mode="3d" slices="3" sliceIndex="axial" />
</service>
<service uid="snapshotAdaptor" type="::visuVTKAdaptor::SSnapshot">
<service uid="snapshotAdaptor" type="sight::module::viz::scene3d::SSnapshot">
<config renderer="default" />
</service>
......
......@@ -3,7 +3,7 @@ CMakeLists coding
.. rule :: Function name
Standard CMake functions and macros should be written in lower case. Each word is generally separated by an underscore (this is a rule of CMake anyway).
Standard CMake functions and macros should be written in lower case.
.. code-block:: cmake
......@@ -12,12 +12,11 @@ CMakeLists coding
.. rule :: Macro name
Custom macros should be written in camel case.
Custom macros should be written in snake case to follow CMake style.
.. code-block:: cmake
fwLoadProperties()
fwLink("boost")
sight_add_target( module_filter_image TYPE MODULE )
.. rule :: Variable name
......@@ -43,7 +42,8 @@ CMakeLists coding
...
endfunction(name)
This is no longer needed in latest CMake versions, and we recommend to use this possibility for the sake of simplicity.
This is no longer needed in latest CMake versions, and we recommend to use this possibility for the sake of
simplicity.
.. code::
......
......@@ -21,7 +21,9 @@ Naming conventions
.. rule :: File
The file's name should end with the shader's type, ``_VP`` for vertex programs, ``_TC`` for tessellation control programs, ``_FE`` for tessellation evalutaion programs, ``_GP`` for geometry programs and ``_FP`` for fragment programs, ``_VP`` for vertex programs and ``_GP`` for geometry programs.
The file name should end with the shader type, ``_VP`` for vertex programs, ``_TC`` for tessellation control
programs, ``_FE`` for tessellation evaluation programs, ``_GP`` for geometry programs and ``_FP`` for fragment
programs, ``_VP`` for vertex programs and ``_GP`` for geometry programs.
.. rule :: Function and method names
......@@ -70,7 +72,11 @@ Naming conventions
- Length : Len
- Size : Size
#. Vectors representing geometrical and matrices transform. You should specify, if possible, their coordinate system. We define the following notation for the most commonly used spaces: (You may read this `documentation <https://www.khronos.org/opengl/wiki/Vertex_Post-Processing#Perspective_divide>`_ if you don't know them) :
#. Vectors and transformation matrices
You should specify, if possible, their coordinate
system. We define the following notation for the most commonly used spaces (see
`OpenGL documentation <https://www.khronos.org/opengl/wiki/Vertex_Post-Processing#Perspective_divide>`_) :
- Texture space : Ts
- Model space : Ms
......@@ -80,9 +86,12 @@ Naming conventions
- Normalized device space : Ns
- Window space : Ss
For vectors, the coordinate system should be appended to the name. In the case of transform matrices, we need to define both, the destination and source spaces, these should be separated by an underscore with the source being last.
For vectors, the coordinate system should be appended to the name. In the case of transformation matrices, we need
to define both, the destination and source spaces, these should be separated by an underscore with the source
being last.
e.g. m4Ss_Ms defines a matrix transforming model vertices to window space points (often known as the model-view-projection matrix)
e.g. m4Ss_Ms defines a matrix transforming model vertices to window space points (often known as the
model-view-projection matrix)
#. If the variable is normalized, the last character must be ``N``.
......
......@@ -108,23 +108,26 @@ In many cases, there are two kind of problems. The program fails to :
- the module that contains this service is not activated in the profile,
- the plugin.xml of the module, that contains this service,
does not declare the service, or the declaration contains mistakes.
- the service is not registered in the Service Factory (forget of macro *fwServicesRegisterMacro(...)* in file .cpp)
- the service is not registered in the Service Factory (forget of macro *SIGHT_REGISTER_SERVICE(...)* in file .cpp)
- manage the configuration of service. In this case, the implementation code
in .cpp file ( generally configuring() method of service ) does not correspond
to the description code in config.xml ( Missing arguments, or not well-formed, or mistakes in string parameters ).
Do I need to convert my data object to a ::fwData::Object ?
Do I need to convert my data object to a sight::data::Object ?
==================================================================================================
Do you need to share this data between services ?
- If the answer is no, then you don't need to wrap your data.
- Otherwise, you need to have an object that inherits of ::fwData::Object.
- Otherwise, you need to have an object that inherits of sight::data::Object.
In this latter case, do you need to share this object between different services which use different third-party libraries, i.e. for ::fwData::Image, itk::Image vs vtkImage ?
In this latter case, do you need to share this object between different services which use different third-party libraries,
i.e. for sight::data::Image, itk::Image vs vtkImage ?
- If the answer is yes, then you need create a new object like fwData::Image and a wrapping with fwData::Image<=>itk::Image and fwData::Image<=>vtkImage.
- Otherwise, you can just encapsulated an itk::Image in fwData::Image and create an accessor on it. ( however, this choice implies that all applications that use fwData::Image need ITK library for running. )
- If the answer is yes, then you need create a new object like sight::data::Image and a wrapping with
sight::data::Image<=>itk::Image and sight::data::Image<=>vtkImage.
- Otherwise, you can just encapsulated an itk::Image in sight::data::Image and create an accessor on it. ( however,
this choice implies that all applications that use sight::data::Image need ITK library for running. )
.. _campPath:
......@@ -146,20 +149,20 @@ For instance, the file *fwDataCamp/Image.cpp* shows :
.. code:: c++
fwCampImplementDataMacro((fwData)(Image))
SIGHT_IMPLEMENT_DATA_REFLECTION((sight)(data)(Image))
{
builder
.tag("object_version", "2")
.tag("lib_name", "fwData")
.base< ::fwData::Object>()
.property("size", &::fwData::Image::m_size)
.property("type", &::fwData::Image::m_type)
.property("spacing", &::fwData::Image::m_spacing)
.property("origin", &::fwData::Image::m_origin)
.property("array", &::fwData::Image::m_dataArray)
.property("nb_components", &::fwData::Image::m_numberOfComponents)
.property("window_center", &::fwData::Image::m_windowCenter)
.property("window_width", &::fwData::Image::m_windowWidth)
.base< sight::data::Object>()
.property("size", &sight::data::Image::m_size)
.property("type", &sight::data::Image::m_type)
.property("spacing", &sight::data::Image::m_spacing)
.property("origin", &sight::data::Image::m_origin)
.property("array", &sight::data::Image::m_dataArray)
.property("nb_components", &sight::data::Image::m_numberOfComponents)
.property("window_center", &sight::data::Image::m_windowCenter)
.property("window_width", &sight::data::Image::m_windowWidth)
;
}
......@@ -174,13 +177,13 @@ For instance the height of the image can be retrieved using:
Other examples:
----------------
To get the image contained in a ``::fwData::Composite`` with the key ``myImage``
To get the image contained in a ``sight::data::Composite`` with the key ``myImage``
.. code:: xml
@values.myImage
To get the first reconstruction of a ModelSeries contained in a ``::fwData::Composite`` with the key ``myModel``
To get the first reconstruction of a ModelSeries contained in a ``sight::data::Composite`` with the key ``myModel``
.. code:: xml
......
......@@ -12,18 +12,18 @@ Application module
This "application module" contains a base configuration to run when the application is launched and lists the required
modules for this configuration.
Like a module, the application folder needs the CMake files and a plugin.xml file. The first difference, is that the
*Properties.cmake* ``TYPE`` is ``APP`` instead of ``MODULE``.
Like a module, the application folder needs the ``CMakeLists.txt`` file and a plugin.xml file. The first difference is that the
``TYPE`` of the ``sight_add_target`` command is ``APP`` instead of ``MODULE``.
The second difference is the line:
.. code-block:: cmake
moduleParam(appXml PARAM_LIST config PARAM_VALUES tutoDataServiceBasicConfig)
It defines the main configuration to be launched by the application (see :ref:`HowTosCMakeProperties.cmake`).
It defines the main configuration to be launched by the application (see :ref:`HowTosCMakeLists.cmake`).
The main configuration should be written in the ``plugin.xml`` file
in a ``<extension implements="::fwServices::registry::AppConfig">`` tag (see :ref:`TutorialsTuto01Basic`).
in a ``<extension implements="sight::service::extension::AppConfig">`` tag (see :ref:`TutorialsTuto01Basic`).
.. _profile.xml:
......@@ -34,13 +34,12 @@ To launch an application, we use:
.. code::
bin/fwlauncher share/<myApplication>_<version>/profile.xml
bin/sightrun share/<myApplication>_<version>/profile.xml
This ``profile.xml`` file, used as an input of the fwlauncher command, holds a list of all modules
This ``profile.xml`` file, used as an input of the sightrun command, holds a list of all modules
necessary to run an application. We describe the content of this file here for reference,
but hopefully you do **not** have to write it yourself.
The Properties.cmake of an application generates automatically a ``profile.xml``.
but hopefully you do **not** have to write it yourself. The ``sight_generate_profile`` macro generates a ``profile.xml``
according to the dependencies you set in the ``CMakeLists.txt`` with ``add_dependencies``.
Here is for example the ``profile.xml`` generated for :ref:`TutorialsTuto01Basic`.
......@@ -51,22 +50,18 @@ Here is for example the ``profile.xml`` generated for :ref:`TutorialsTuto01Basic
<profile name="Tuto01Basic" version="0.2" check-single-instance="false">
<activate id="Tuto01Basic" version="0.2" />
<activate id="appXml" version="0.2" >
<activate id="sight::module::appXml" version="0.2" >
<param id="config" value="Tuto01Basic_AppCfg" />
</activate>
<activate id="gui" version="0.1" />
<activate id="guiQt" version="0.1" />
<activate id="servicesReg" version="0.1" />
<start id="appXml" />
<start id="guiQt" />
<start id="sight::module::appXml" />
<start id="sight::module::ui::qt" />
</profile>
activate:
List of modules used in this application. We see the parameter given to *appXML* module that
we wrote in the *Properties.cmake*.
we wrote in the *CMakeLists.txt*.
start:
List of modules to start when the application is launched. Basically,
......
......@@ -7,110 +7,53 @@ Introduction
-------------
Sight and its dependencies are built with `CMake <http://www.cmake.org/>`_ .
Note that the minimal version of cmake to have is 3.9.
Each project (apps, modules, libs) has two "CMake" files:
- CMakeLists.txt_
- Properties.cmake_
Note that the minimal required version of CMake is 3.13.
CMakeLists.txt
---------------
The *CMakeLists.txt* should contain at least the function *fwLoadProperties()* to load the Properties.cmake.
But it can also contain others functions useful to link with external libraries.
.. _HowTosCMakeLists.cmake:
Here is an example of CMakeLists.txt from guiQt Module :
Each target (application, module, library) contains one `CMakeLists.txt`. We use
standard CMake commands and properties, and a few custom macros.
.. code-block:: cmake
The *CMakeLists.txt* should contain the macro *sight_add_target()* which will create the correct CMake target depending
on the TYPE parameter:
fwLoadProperties()
- APP for a XML-based application
- MODULE for a module
- LIBRARY for a library
- EXECUTABLE for an executable
find_package(Qt5 COMPONENTS Core Gui Widgets REQUIRED)
Then you can use classic CMake commands to link with others sight libaries or with external libraries.
Here is an example of CMakeLists.txt of sample module which links with Qt5:
fwInclude(
${Qt5Core_INCLUDE_DIRS}
${Qt5Gui_INCLUDE_DIRS}
${Qt5Widgets_INCLUDE_DIRS}
)
.. code-block:: cmake
fwLink(
${Qt5Core_LIBRARIES}
${Qt5Gui_LIBRARIES}
${Qt5Widgets_LIBRARIES}
)
sight_add_target(module_foo TYPE MODULE)
set_target_properties(${FWPROJECT_NAME} PROPERTIES AUTOMOC TRUE)
find_package(Qt5 COMPONENTS Core Gui Widgets REQUIRED)
target_link_libraries(module_foo PRIVATE Qt5::Core Qt5::Gui Qt5::Widgets)
The first line *fwLoadProperties()* will load the *Properties.cmake* (see explanation in the next section).
set_target_properties(module_foo PROPERTIES AUTOMOC TRUE)
The next lines allows to compile with the support of some external libraries (sight-deps), in this example this is Qt.
The first thing to do is to discover where Qt is installed. This is done with the regular CMake command ``find_package(The_lib COMPONENTS The_component)``.
Then we use ``fwInclude`` to add includes directories to the target, and ``fwLink`` to link the libraries with your target.
Actually if you're accustomed to CMake these two macros are strictly equivalent to:
.. code-block:: cmake
target_include_directories( ${FWPROJECT_NAME} SYSTEM PRIVATE ${Qt5Core_INCLUDE_DIRS} ${Qt5Gui_INCLUDE_DIRS} ${Qt5Widgets_INCLUDE_DIRS} )
target_link_libraries( ${FWPROJECT_NAME} PRIVATE ${Qt5Core_LIBRARIES} ${Qt5Gui_LIBRARIES} ${Qt5Widgets_LIBRARIES} )
They are proposed as a convenience so people won't forget for instance to specify `SYSTEM`,
which prevents compilation warnings from third-part libraries to be displayed.
If the rare case where your module may be a dependency of an another one,
you can forward the include directories and the libraries with ``fwForwardInclude`` and ``fwForwardLink``,
which are still equivalent to ``target_include_directories``
and ``target_link_libraries`` CMake commands but with ``PUBLIC`` set instead of ``PRIVATE``.
Eventually, you can also add custom properties to your target with ``set_target_properties``.
.. _HowTosCMakeProperties.cmake:
Properties.cmake
-----------------
Properties.cmake should contain informations like name, version, dependencies and requirements of the current target.
Here is an example of Properties.cmake from ``fwData`` library:
.. code-block:: cmake
set( NAME fwData )
set( VERSION 0.1 )
set( TYPE LIBRARY )
set( DEPENDENCIES fwCom fwMemory fwTools )
set( REQUIREMENTS )
NAME:
Name of the target
VERSION:
Version of the target
TYPE:
Define the type of the target:
- APP for an "Application"
- MODULE for a "module"
- LIBRARY for a "library"
- EXECUTABLE for an executable
DEPENDENCIES:
Link the target with the given libraries (see `target_link_libraries <http://www.cmake.org/cmake/help/v3.0/command/target_link_libraries.html?highlight=target_link_libraries>`_ ).
The DEPENDENCIES should contain only "library".
REQUIREMENTS:
Ensure that the dependencies are built before the targets (see `add_dependencies <http://www.cmake.org/cmake/help/v3.0/command/add_dependencies.html?highlight=add_dependencies>`_ ).
The REQUIREMENTS should contain only "modules".
Modules without C++ code, like XML-based applications or activities need to ensure that the necessary modules are
built. To achieve that, we use the `add_dependencies()` CMake command.
In some Properties.cmake (mostly in applications), you can see the line:
Last, in XML-based in applications, you will find the line:
.. code-block:: cmake
moduleParam(appXml PARAM_LIST config PARAM_VALUES tutoBasicConfig)
This CMake macro allows to give parameters to a module. The parameters are defined like:
This custom CMake macro allows to pass parameters to a module. The parameters are defined like:
.. code-block:: cmake
......
<
.. _HowTosModuleCreation:
*******************************************************************
How to create a module, a lib, an executable or an application ?
How to create a module ?
*******************************************************************
In sight, the modules, libraries, applications and executables are folders containing:
- [required] two files to generate the *CMake* target: ``CMakeLists.txt``
and ``Properties.cmake`` (see :ref:`HowTosCMake`).
- [optional] *include* and *src* folder to contain the header and source files.
- [optional] *rc* folder to contain resources and XML configuration files
- [optional] *test* folder to contain the unit tests
How to create a module ?
==========================
In *Sight*, there are mostly two types of modules:
In sight, you will encounter two types of modules:
- the modules containing only XML configurations
- the modules containing services or other cpp code
- the modules containing only resource files, for instance XML configurations
- the modules containing services or other C++ code