Commit bfbfc4d5 authored by Genial-O's avatar Genial-O
Browse files

merge(dev): release 20.0.0

parents b0f678d7 7f1983cf
......@@ -23,3 +23,5 @@ syntax: glob
# vs cmake project files
\.vs*
CMakeSettings\.json
_build/
......@@ -9,7 +9,7 @@ sheldon-mr:
stage: sheldon
script:
- export ORIG_BRANCH_COMMIT_SHA=$(git merge-base dev origin/${CI_COMMIT_REF_NAME})
- git -c http.sslVerify=false clone --depth 1 https://gitlab-ci-token:${CI_JOB_TOKEN}@git.ircad.fr/Sight/sight-git.git
- 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}
......@@ -17,14 +17,14 @@ sheldon:
image: ${DOCKER_ENVDEV_MINT19}
stage: sheldon
script:
- git -c http.sslVerify=false clone --depth 1 https://gitlab-ci-token:${CI_JOB_TOKEN}@git.ircad.fr/Sight/sight-git.git
- 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:3
image: python:alpine
stage: lint
script:
- pip install doc8 Pygments
......@@ -39,11 +39,11 @@ markdown-lint:
- markdownlint --config .markdownlint.json .
build-doc:
image: python:3
image: python:alpine
stage: build
script:
- pip install sphinx sphinx_rtd_theme sphinx-tabs
- apt-get update && apt-get install -yqq make
- apk add make
- make html
artifacts:
name: "$CI_JOB_NAME-$CI_COMMIT_REF_SLUG"
......
......@@ -13,7 +13,7 @@
* Compiler: (gcc/clang/... & version)
* Build type: (debug/release)
* Commit: (current commit or tag)
* (Any related repository commit/tag e.g fw4spl-deps, fw4spl, fw4spl-ar ...)
* (Any related repository commit/tag e.g conan, sight, sight-doc ...)
### What is the current *bug* behavior?
......
### Description
(Description of the feature to be implemented as a story: task of a project work package, associated deliverable ...)
### Task list
(The complete task list must be created at the issue creation and then the associated issue links must be appended to each associated task)
- [ ] Task 1
- [ ] Task 2
- [ ] ...
/label ~"Type:story"
## What does this MR do?
## Description
(Briefly describe what this MR is about)
Closes #number
## How to test it?
(Describe how to test this feature step by step)
......@@ -20,13 +22,3 @@
- [ ] Build on Windows
- [ ] ...
## Associated Issues/Merge Requests
- Issues
- Fixes repo#number
- [ ] depends on repo#number
- Merge requests
- See also repo!number
- [ ] depends on repo!number
......@@ -92,7 +92,7 @@ Source and files
.. rule :: Sort headers inclusions
You must sort headers in the following order : same module, framework libraries, bundles, external libraries, standard library. This way, this helps to make each header independent. The rule can be broken if a different include order is necessary to get a successful build.
You must sort headers in the following order : same module, framework libraries, modules, external libraries, standard library. This way, this helps to make each header independent. The rule can be broken if a different include order is necessary to get a successful build.
.. code-block :: cpp
......@@ -125,6 +125,61 @@ Source and files
#include <map>
#include <vector>
.. rule :: Deprecated code
When you want to deprecate a piece of code, you need to warn other developers that the piece of code they are using is deprecated.
1. Use C++17 deprecated keyword (always)
The general rule is that you need to use the keyword ``[[deprecated("message")]]``.
The "message" should indicate **when** the function will be removed.
We use a timelapse of **two(2)** major versions before removing previously deprecated function. Ex: you want to remove ``functionA()`` and the current release is sight 20.0
the code will look like:
.. code-block :: cpp
[[deprecated("will be removed in sight 22.0, please use functionB().")]]
void functionA();
In case of deprecating an entire class, you may need to add the keyword on constructor, or at class level.
2. Use doxygen tag ``@deprecated`` (when needed)
In addition of the C++17 keyword, you may also want to add doxygen tag ``@deprecated``,
like the keyword it must contain the version where the function will be removed.
.. code-block :: cpp
/**
* @brief Computes the A value.
* @deprecated: will be removed in sight 22.0, please use functionB() instead.
**/
[[deprecated("will be removed in sight 22.0, please use functionB().")]]
void functionA();
3. Use a logging macro (carefully)
In some particular cases, you will need to use a macro that prints a deprecated message as output (console or SLM.log file).
Be careful when using macro, because if the function is widely used, it can slow down the whole application.
That's why deprecated macros are reserved for very specific usages:
- **slots**: since our slots can be called by an xml configuration, you may need to warn the user using a message.
- **piece of code**: when you want to deprecate just a piece of code (loop, if/else, ...).
- **Changing XML parameters/config**:when an xml configuration or a parameter is deprecated you may want to print a message when user use it.
.. code-block :: cpp
void SNegato2D::newImageDeprecatedSlot()
{
FW_DEPRECATED_MSG("The 'newImage' slot will be removed in sight 21.0. Call 'update' instead.", "21.0");
this->newImage();
}
For more details about macros, please check the doxygen page of spyLog.hpp
Naming conventions
------------------
......@@ -230,7 +285,8 @@ Naming conventions
.. rule :: Enumerated type
An enumerated type name must be written in upper camel case. Labels must be written in capitals. If a ``typedef`` is defined, it follows the upper camel case standard.
An enumerated type name must be written in upper camel case. Labels must be written in capitals.
If a ``typedef`` is defined, it follows the upper camel case standard.
.. code-block :: cpp
......@@ -503,7 +559,7 @@ Miscellaneous
.. rule :: Use of namespaces
You have to organize your code inside namespaces. By default, you will have at least one namespace for your module (application or bundle). Inside this namespace, it is recommended to split your code into sub-namespaces. This helps notably to prevent naming conflicts.
You have to organize your code inside namespaces. By default, you will have at least one namespace for your module (application or module). Inside this namespace, it is recommended to split your code into sub-namespaces. This helps notably to prevent naming conflicts.
It is forbidden to use the expression``using namespace`` in header files but it is allowed in implementation files. It is however recommended to use aliases in this latter case.
......
......@@ -26,7 +26,7 @@ The three main concepts of the architecture, explained in the following sections
- component approach
- signal-slot communication
The framework is multi-platform and runs under Windows, Linux, and MacOS.
The framework is multi-platform and runs under Windows and Linux.
Building an application with Sight only requires to write one or several XML files.
Its functionalities can be also extended by writing new components in C++,
which is the coding language of the framework.
......@@ -35,7 +35,7 @@ which is the coding language of the framework.
Which platforms does sight run on?
===================================
This framework can run under Windows, Linux and MacOS.
This framework can run under Windows and Linux.
Where can I find applications developed with sight ?
======================================================
......@@ -43,7 +43,7 @@ Where can I find applications developed with sight ?
Some tutorials are provided with the framework and you can also build VRRender,
a free visualization software or ARCalibration, a user-friendly camera calibration tool.
Which prerequisites do I need to develop new services and bundles ?
Which prerequisites do I need to develop new services and modules ?
=====================================================================
You must have a good knowledge in C++. Concerning the configuration files, they are written in XML.
......@@ -58,7 +58,7 @@ They can be downloaded on https://git.ircad.fr/sight/sight-deps.
Is it difficult to compile an application with sight?
======================================================
No, it isn't. You just have to compile all the bundles and libraries used by the application.
No, it isn't. You just have to compile all the modules and libraries used by the application.
Please follow the :ref:`installation instructions<Installation>` for your platform.
Why does sight provide a launcher?
......@@ -89,12 +89,12 @@ Lower levels are really designed to be activated punctually when debugging a spe
Secondly, you can of course compile your application in Debug mode (set **CMAKE_BUILD_TYPE** to "Debug" )
and then debug it using **gdb** (Linux/Mac), **QtCreator** (Linux/Mac), **Visual Studio** (Windows).
and then debug it using **gdb** (Linux), **QtCreator** (Linux/Windows), **Visual Studio** (Windows).
Thirdly, you can manage the program complexity by reducing the number of activated components (in profile.xml)
and the number of created services (in config.xml) to better localize errors.
Fourthly, verify that your profile.xml / plugin.xml and each bundle plugin.xml are well-formed,
Fourthly, verify that your profile.xml / plugin.xml and each module plugin.xml are well-formed,
by using xmllint (command line tool provided by libxml2).
I have an assertion/fatal message when I launch my program, any idea to correct the problem ?
......@@ -103,15 +103,15 @@ I have an assertion/fatal message when I launch my program, any idea to correct
First, you can read the output message :) and try to solve the problem.
In many cases, there are two kind of problems. The program fails to :
- create the service given in configuration. In this case, four reasons are possibles :
- the name of service implementation in *config.xml* contains mistakes
- the bundle that contains this service is not activated in the profile
- the bundle plugin.xml, that contains this service,
does not declare the service or the declaration contains mistakes.
- create the service given in configuration. In this case, four reasons are possible :
- the name of service implementation in *config.xml* contains mistakes,
- 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)
- manage the configuration of service. In this case, the implementation code
in .cpp file ( generally configuring() method of service ) does not correspond
to description code in config.xml ( Missing arguments, or not well-formed, or mistakes string parameters ).
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 ?
==================================================================================================
......@@ -164,7 +164,7 @@ For instance, the file *fwDataCamp/Image.cpp* shows :
}
Which means that each property is a reachable by a **camp path**.
This is notably used by services in the ``ctrlCamp`` bundle, like ``SExtractObjObj`` or ``SCopy``.
This is notably used by services in the ``ctrlCamp`` module, like ``SExtractObjObj`` or ``SCopy``.
For instance the height of the image can be retrieved using:
.. code:: xml
......
......@@ -5,22 +5,22 @@ How to create a XML based application ?
****************************************
In the Tutorials, we explain how to create simple applications.
A XML based application, is defined by an "application bundle" (like a bundle but with some differences that we will
A XML based application, is defined by an "application module" (like a module but with some differences that we will
describe further).
Application bundle
Application module
-------------------
This "application bundle" contains a base configuration to run when the application is launched and lists the required
bundles for this configuration.
This "application module" contains a base configuration to run when the application is launched and lists the required
modules for this configuration.
Like a bundle, 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 ``BUNDLE``.
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``.
The second difference is the line:
.. code-block:: cmake
bundleParam(appXml PARAM_LIST config PARAM_VALUES tutoDataServiceBasicConfig)
moduleParam(appXml PARAM_LIST config PARAM_VALUES tutoDataServiceBasicConfig)
It defines the main configuration to be launched by the application (see :ref:`Properties.cmake`).
......@@ -38,7 +38,7 @@ To launch an application, we use:
bin/fwlauncher share/<myApplication>_<version>/profile.xml
This ``profile.xml`` file, used as an input of the fwlauncher command, holds a list of all bundles
This ``profile.xml`` file, used as an input of the fwlauncher 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``.
......@@ -68,17 +68,17 @@ Here is for example the ``profile.xml`` generated for :ref:`tuto01`.
</profile>
activate:
List of bundles used in this application. We see the parameter given to *appXML* bundle that
List of modules used in this application. We see the parameter given to *appXML* module that
we wrote in the *Properties.cmake*.
start:
List of bundles to start when the application is launched. Basically,
there are a few bundles to start at the beginning:
List of modules to start when the application is launched. Basically,
there are a few modules to start at the beginning:
- *appXML*: to launch the configuration
- *guiQt*: to launch the qt event loop for applications with a GUI
- *memory*: to manage image and mesh buffers
The other bundles will be started according to the XML <requirement> tags of the bundles,
or when a service is used in an XML configuration and its bundle is not started.
The other modules will be started according to the XML <requirement> tags of the modules,
or when a service is used in an XML configuration and its module is not started.
That way we only have the minimum number of shared libraries loaded.
......@@ -10,7 +10,7 @@ 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, bundles, libs) has two "CMake" files:
Each project (apps, modules, libs) has two "CMake" files:
- CMakeLists.txt_
- Properties.cmake_
......@@ -23,7 +23,7 @@ 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.
Here is an example of CMakeLists.txt from guiQt Bundle :
Here is an example of CMakeLists.txt from guiQt Module :
.. code-block:: cmake
......@@ -60,7 +60,7 @@ Actually if you're accustomed to CMake these two macros are strictly equivalent
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 bundle may be a dependency of an another one,
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``.
......@@ -94,7 +94,7 @@ TYPE:
Define the type of the target:
- APP for an "Application"
- BUNDLE for a "bundle"
- MODULE for a "module"
- LIBRARY for a "library"
- EXECUTABLE for an executable
......@@ -104,19 +104,19 @@ DEPENDENCIES:
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 "bundles".
The REQUIREMENTS should contain only "modules".
In some Properties.cmake (mostly in applications), you can see the line:
.. code-block:: cmake
bundleParam(appXml PARAM_LIST config PARAM_VALUES tutoBasicConfig)
moduleParam(appXml PARAM_LIST config PARAM_VALUES tutoBasicConfig)
This CMake macro allows to give parameters to a bundle. The parameters are defined like:
This CMake macro allows to give parameters to a module. The parameters are defined like:
.. code-block:: cmake
bundleParam(<bundle>
moduleParam(<module>
PARAM_LIST <param1_name> <param2_name> <param3_name>
PARAM_VALUES <param1_value> <param2_value> <param3_value>
)
......@@ -127,13 +127,13 @@ These parameters can be retrieved in the ``Plugin.cpp`` like:
void Plugin::start()
{
if( this->getBundle()->hasParameter("param1_name") )
if( this->getModule()->hasParameter("param1_name") )
{
const std::string param1Value = this->getBundle()->getParameterValue("param1_name");
const std::string param1Value = this->getModule()->getParameterValue("param1_name");
}
if( this->getBundle()->hasParameter("param2_name") )
if( this->getModule()->hasParameter("param2_name") )
{
const std::string param2Value = this->getBundle()->getParameterValue("param2_name");
const std::string param2Value = this->getModule()->getParameterValue("param2_name");
}
// ...
}
......
*******************************************************************
How to create a bundle, a lib, an executable or an application ?
How to create a module, a lib, an executable or an application ?
*******************************************************************
In sight, the bundles, libraries, applications and executables are folders containing:
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:`HowCMake`).
......@@ -10,33 +10,33 @@ In sight, the bundles, libraries, applications and executables are folders conta
- [optional] *rc* folder to contain resources and XML configuration files
- [optional] *test* folder to contain the unit tests
.. _bundleCreation:
.. _moduleCreation:
How to create a bundle ?
How to create a module ?
==========================
In sight, you will encounter two types of bundles:
In sight, you will encounter two types of modules:
- the bundles containing only XML configurations
- the bundles containing services or other cpp code
- the modules containing only XML configurations
- the modules containing services or other cpp code
It is possible to contain at the same time configurations and services (or C++ code), but for the sake of clarity and
reusability we recommend to separate the two.
.. _configBundle:
.. _configModule:
XML configurations bundles
XML configurations modules
--------------------------
These bundles does not contain C++ code, they only contain XML files and the required *CMake* files.
In the bundle folder, there is only the *CMake* files and the *rc* folder.
These modules does not contain C++ code, they only contain XML files and the required *CMake* files.
In the module folder, there is only the *CMake* files and the *rc* folder.
CMake files
~~~~~~~~~~~~
The CMakeLists.txt contains only ``fwLoadProperties()`` to load the Properties.cmake
The Properties.cmake defines the bundles needed to launch the configuration (ie. the bundle of all the services present
The Properties.cmake defines the modules needed to launch the configuration (ie. the module of all the services present
in the configurations).
Example:
......@@ -45,10 +45,10 @@ Example:
set( NAME dataManagerConfig )
set( VERSION 0.1 )
set( TYPE BUNDLE )
set( TYPE MODULE )
set( DEPENDENCIES ) # no dependency
set( REQUIREMENTS # required bundle
set( REQUIREMENTS # required module
gui
guiQt
uiMedDataQt
......@@ -60,7 +60,7 @@ Example:
Configurations
~~~~~~~~~~~~~~~
A bundle could contain several configurations, they are in the ``plugin.xml`` file in the *rc* folder.
A module could contain several configurations, they are in the ``plugin.xml`` file in the *rc* folder.
.. code-block:: xml
......@@ -75,7 +75,7 @@ A bundle could contain several configurations, they are in the ``plugin.xml`` fi
The ``@PROJECT_VERSION@`` will be automatically replaced by the version defined in the Properties.cmake.
The ``<requirement>`` tags contain the bundles that must be started before to start your bundle (see https://sight.pages.ircad.fr/sight/group__requirement.html).
The ``<requirement>`` tags contain the modules that must be started before to start your module (see https://sight.pages.ircad.fr/sight/group__requirement.html).
Then the extensions are defined. There are different types of extensions, the most common are:
......@@ -90,19 +90,19 @@ Then the extensions are defined. There are different types of extensions, the mo
To separate the configuration in several files, you can use ``<xi:include href="..." />``
.. _serviceBundle:
.. _serviceModule:
Service bundles
Service modules
----------------
You don't need to create the ``plugin.xml`` file for the bundle that contains only services,
You don't need to create the ``plugin.xml`` file for the module that contains only services,
it will be automatically generated.
A ``CMake`` script parses the services macro and doxygen
to generate the ``::fwServices::registry::ServiceFactory`` extension
(see :ref:`serviceCreation` and :ref:`serviceNotFound`)
The bundle contains the service header files in the `include` folder and the `source` files in the `src` folder.
It must also contain a ``Plugin`` class used to register the bundle.
The module contains the service header files in the `include` folder and the `source` files in the `src` folder.
It must also contain a ``Plugin`` class used to register the module.
The ``Plugin.hpp`` in the *include* folder should look like:
......@@ -112,10 +112,10 @@ The ``Plugin.hpp`` in the *include* folder should look like:
#include <fwRuntime/Plugin.hpp>
namespace myBundle
namespace myModule
{
class MYBUNDLE_CLASS_API Plugin : public ::fwRuntime::Plugin
class MYMODULE_CLASS_API Plugin : public ::fwRuntime::Plugin
{
public:
......@@ -123,21 +123,21 @@ The ``Plugin.hpp`` in the *include* folder should look like:
/// Plugin destructor
~Plugin() noexcept;
/// This method is used by runtime to start the bundle.
/// This method is used by runtime to start the module.
void start();
/// This method is used by runtime to stop the bundle.
/// This method is used by runtime to stop the module.
void stop() noexcept;
/// This method is used by runtime to initialize the bundle.
/// This method is used by runtime to initialize the module.
void initialize();
/// This method is used by runtime to uninitialize the bundle.
/// This method is used by runtime to uninitialize the module.
void uninitialize() noexcept;
};
} // namespace myBundle
} // namespace myModule
The ``Plugin.cpp`` in the *src* folder should be like:
......@@ -146,14 +146,14 @@ The ``Plugin.cpp`` in the *src* folder should be like:
#include <fwRuntime/utils/GenericExecutableFactoryRegistrar.hpp>
#include "myBundle/Plugin.hpp"
#include "myModule/Plugin.hpp"
namespace myBundle
namespace myModule
{
//-----------------------------------------------------------------------------
static ::fwRuntime::utils::GenericExecutableFactoryRegistrar<Plugin> registrar("::myBundle::Plugin");
static ::fwRuntime::utils::GenericExecutableFactoryRegistrar<Plugin> registrar("::myModule::Plugin");
//-----------------------------------------------------------------------------
......@@ -187,14 +187,14 @@ The ``Plugin.cpp`` in the *src* folder should be like:
//-----------------------------------------------------------------------------
} // namespace myBundle
} // namespace myModule
.. warning::
The ``registrar("::myBundle::Plugin");`` is the most important line, it allows to register the bundle to be used in a XML based application.
The ``registrar("::myModule::Plugin");`` is the most important line, it allows to register the module to be used in a XML based application.
**Don't forget to register the bundle with the correct namespace with '::'.**
**Don't forget to register the module with the correct namespace with '::'.**
The methods ``start()`` and ``stop`` must be implemented but are usually empty. They are called when the application is
started and stopped. The ``initialize()`` method is executed after the *start* of all the bundles and ``uninitialize()`` before the *stop*.
started and stopped. The ``initialize()`` method is executed after the *start* of all the modules and ``uninitialize()`` before the *stop*.
......@@ -15,10 +15,10 @@ A service is a C++ class inherited from ``::fwServices::IService``. It will impl
These methods are called by the *configure()*, *start()*, *update()* and *stop()* slots of the base class ``IService``.
For the example, we will create a service ``SMesher`` in a bundle ``operators``. The service will have a
For the example, we will create a service ``SMesher`` in a module ``operators``. The service will have a
``::fwData::Image`` as input and a ``::fwData::Mesh`` as output.
The header file ``SMesher.hpp`` should be in the folder ``<src_dir>/bundles/operators/include/operators``:
The header file ``SMesher.hpp`` should be in the folder ``<src_dir>/modules/operators/include/operators``:
.. code-block:: cpp
......@@ -99,7 +99,7 @@ macros that allow to expose symbols in the shared library.
- *description*: the purpose of this input/output
In the source file ``SMesher.cpp`` should be in the folder ``<src_dir>/bundles/operators/src/operators``:
In the source file ``SMesher.cpp`` should be in the folder ``<src_dir>/modules/operators/src/operators``:
.. code-block:: cpp
......@@ -148,8 +148,8 @@ In the source file ``SMesher.cpp`` should be in the folder ``<src_dir>/bundles/o
void SMesher::updating()
{
// retrieve the image
::fwData::Image::csptr image = this->getInput< ::fwData::Image >(s_IMAGE_INPUT);
SLM_ASSERT("Input '" + s_IMAGE_INPUT + "' is not defined", image);
auto lockedImage = this->getLockedInput< ::fwData::Image >(s_IMAGE_INPUT);
SLM_ASSERT("Input '" + s_IMAGE_INPUT + "' is not defined", lockedImage);
::fwData::Mesh::sptr mesh = ::fwData::Mesh::New();
......
......@@ -7,8 +7,8 @@ How to fix my bug?
My data is not found
-----------------------
#. Is the data properly written in your XML configuration? Don't forget the ``::``.
#. Is the xxDataReg bundle in your application/activity requirement?
Where xxDataReg is the bundle that register the library containing your data (dataReg, arDataReg, ...).
#. Is the xxDataReg module in your application/activity requirement?
Where xxDataReg is the module that register the library containing your data (dataReg, arDataReg, ...).
.. _serviceNotFound:
......@@ -17,45 +17,45 @@ My service is not found
#. Is the service properly written in your XML configuration? Dont't forget the ``::``?
#. Did you call ``cmake`` after adding the new files?
You need to call ``cmake .`` in your build repository to ensure that the files are built.
#. Is the bundle of your service added in your application/activity Properties.cmake?
#. Is the bundle properly registered? See :ref:`bundleCreation`
#. Is the module of your service added in your application/activity Properties.cmake?
#. Is the module properly registered? See :ref:`moduleCreation`
#. Is the plugin.xml properly generated?
For example with a bundle named ``myBundle`` with version ``0.2`` containing the service ``SMyService``:
It must be written in ``<build_dir>/share/myBundle_0.2/plugin.xml``
For example with a module named ``myModule`` with version ``0.2`` containing the service ``SMyService``:
It must be written in ``<build_dir>/share/myModule_0.2/plugin.xml``
.. code-block:: xml