1. 04 Jun, 2020 3 commits
  2. 02 Jun, 2020 3 commits
  3. 29 May, 2020 1 commit
  4. 28 May, 2020 1 commit
  5. 27 May, 2020 1 commit
    • Emilie WERNERT's avatar
      refactor(fwData): clean fwData and fwTest with new API of Image, Mesh and Array · 6b1122fc
      Emilie WERNERT authored
      Merge branch 'new-data-api-2' into 'dev'
      
      * Update `config.hpp.in` to add `<PROJECT_NAME>_DEPRECATED_CLASS_API`, it allows to set the `deprecated` attribut on a class (display a compilation warning).
      * Update `fwTest` and `fwData` libraries to remove the dependency to `fwDataTools`
      * Clean `fwDataTools` to remove the use of deprecated helpers, but the helpers are still here.
      * fix SImagesBlend adaptor: fix size, spacing and origin comparison
      
      Closes #473
      
      See merge request sight/sight!393
      6b1122fc
  6. 25 May, 2020 7 commits
  7. 22 May, 2020 1 commit
  8. 20 May, 2020 4 commits
  9. 19 May, 2020 1 commit
  10. 18 May, 2020 5 commits
  11. 15 May, 2020 4 commits
    • Flavien BRIDAULT-LOUCHEZ's avatar
    • rmanciaux's avatar
      fix(ioDcmtk): don't set m_readFailed to true · 89857395
      rmanciaux authored
      89857395
    • Flavien BRIDAULT-LOUCHEZ's avatar
      fix(Sight): fail to compile with Clang · 5f77173b
      Flavien BRIDAULT-LOUCHEZ authored
      This adds the AES flag for Clang, allowing to build fwZip successfully. 
      
      Initially, the MR was opened to fix this issue but actually many targets failed to compile with Clang, thus other minor fixes are included.
      
      Closes #482 
      Merge branch '482-fwzip-fail-to-compile-with-clang' into 'dev'
      See merge request Sight/sight!401
      5f77173b
    • Flavien BRIDAULT-LOUCHEZ's avatar
      refactor(fwRuntime): rename 'Bundle' into 'Module'" · 1ead4ff8
      Flavien BRIDAULT-LOUCHEZ authored
      The first intent of this MR is to rename the term 'Bundle' into 'Module'. As stated in #404, '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. 🕯 
      
      Closes #404
      Merge branch '404-rename-bundle-to-module' into 'dev'
      See merge request Sight/sight!282
      1ead4ff8
  12. 14 May, 2020 8 commits
  13. 13 May, 2020 1 commit