(fwRuntime): rename 'Bundle' into 'Module'"

What does this MR do?

Where to start ? Errmm.

The first intent of this MR is to rename the term 'Bundle' into 'Module'. As stated in #404 (closed), 'Bundle' is not a term widely spread in software for the meaning we give to it. More often, software use either the term 'Module' or 'Plugin'. Late in summer 2019, we decided to choose 'Module'.

However we did not want that change to be a breaking change. So as usual, during two major versions, 'Bundle' and 'Module' terms are likely to coexist and the old API should be deprecated but maintained. Most code mentioning 'Bundle' lies in fwRuntime. I realized a lot of code present in that library was never used outside. It would have been useless to double every method and class for non-public code.

I've been keeping saying we do not clearly separate public and private API in our libraries. I decided so to try to achieve that in fwRuntime. After doing this, the only deprecation of the public API will be faster.

To separate the private and the public API in Sight libraries, I propose to add detail folders both in include and src folders. Symbols in detail folders will be hidden/not exported, thus reducing the size of the shared library and speeding up debugging (when doing this at a large scale of course). This has many advantages in terms of readability of code, maintenance (like this deprecation), etc...

However, one drawback is that since symbols are not exported, it was no longer possible to unit-test private classes and methods. To overcome this, I propose to compile libraries in two steps. One OBJECT_LIBRARY, then the usual SHARED_LIBRARY, that uses the previous as input of course. This way, the unit-test can build directly with the OBJECT_LIBRARY (so the precompiled .obj) directly, removing the need of export, and allowing the test of private classes and methods.

But, this was not that simple. In our tests that are often more functional tests than unit-tests, we face two issues:

• we have circular dependencies between libraries, so the test may try to link against both the OBJECT_LIBRARY and the SHARED_LIBRARY, causing awful runtime errors,
• we use lots of static singletons to register types, factories, etc... The same singleton may be instanced both in the OBJECT_LIBRARY and the SHARED_LIBRARY, ending up with a doublon and not a singleton.

The first issue can be tackled, I tried at some point, but it was quite hard, especially as soon as we load modules. The second is even harder sometimes. At the end I chose an alternative. I propose to split tests in two. One for the public API (ex: fwRuntimeTest) and one for the implementation (ex: fwRuntimeImplTest). The implementation test should be much more minimal and should not require many dependencies, thus reducing the possibility of these two problems to occur. At least that's my hope. 🕯

What's next ?

To prove that this MR does not break anything, I tried to change as less as possible the code outside fwRuntime. I only renamed Bundle into Module in comments outside it.

After the merge, I will propose a MR that removes the usage of deprecated methods. I will also propose the renaming of the Bundles folder into modules. I would also recommend to rename SrcLib into lib which also sounds more common.

How to test it?

This is not a breaking change, but this is a big change. 🙂

• Run as many things as you want... Apps, samples, unit-tests,...

Associated Issues/Merge Requests

• Issues
  • Closes #404 (closed)