CamiTK Community Edition issueshttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues2024-03-22T18:08:56+01:00https://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/182Update Ubuntu docker fo CI2024-03-22T18:08:56+01:00Emmanuel PromayonUpdate Ubuntu docker fo CIUpdate LTS docker image using Ubuntu 24.04 LTS Noble [Numbat](https://en.wikipedia.org/wiki/Numbat) that [will be released at the end of April](https://discourse.ubuntu.com/t/noble-numbat-release-schedule/35649)
**Question to answer:**
...Update LTS docker image using Ubuntu 24.04 LTS Noble [Numbat](https://en.wikipedia.org/wiki/Numbat) that [will be released at the end of April](https://discourse.ubuntu.com/t/noble-numbat-release-schedule/35649)
**Question to answer:**
- if the windows tool chain migrates to MSys2 (i.e. using mingw64 compiler instead of MSC++), would it not be better to use lvm instead of gcc on LTS so that there are at least two big compiler family in the CI?
**Note**
Use tag `:2025` for the image instead of `5.3` (change of docker image naming convention)
***Note***
Depends on Ubuntu 24.04 release, this should be planned for may/june.
- [ ] update Dockerfile
- [ ] setup CI using new image
- [ ] push image to gitlab
- [ ] update website setup documentation
- [ ] update [support policy web page](https://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/DevTeam/camitk-website/-/blob/master/content/en/docs/advanced%20topics/developers/support%20policy.md)
- [ ] in the `develop` branch check `CMakeLists.txt` for minimal version and check if update is required
- [ ] in the `develop` branch move version requirements for the tests (VTK and ITK version) and update test file if required. For instance : `component-stl-level3-2`, `vtkimage`...Emmanuel PromayonEmmanuel Promayonhttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/183Update Windows toolchain and docker fo CI2024-03-25T18:19:08+01:00Emmanuel PromayonUpdate Windows toolchain and docker fo CI| | |
|--|--|
| **As a** | CamiTK developer |
| **I would like to** | have a new toolchain on windows and a new docker image for CI |
| **So that** | I spend less time on installing and building CamiTK CE |
| | |
|--|--|
| **As a** | CE...| | |
|--|--|
| **As a** | CamiTK developer |
| **I would like to** | have a new toolchain on windows and a new docker image for CI |
| **So that** | I spend less time on installing and building CamiTK CE |
| | |
|--|--|
| **As a** | CEP developer on Windows |
| **I would like to** | have a simpler way to install the toolchain and develop my extension |
| **So that** | I spend less time on the setup and have less difficulties to develop on Windows |
## Description / Overview
Windows setup is fastidious and can have side effect on the installation (or the local installation can have side effect on the CEP development, e.g. installation of some LaTeX software provides Qt DLL that conflict with the CamiTK setup).
Some package/dev environment setup systems exist on Windows
- [msys2](https://www.msys2.org/) has an [extensive list of available packages](https://github.com/msys2/MINGW-packages), and a [good documentation](https://www.msys2.org/docs/package-management/). The compiler is mingw64.
- chocolatey (that what is used at the moment). The compiler is MSVC
- [vcpkg](https://learn.microsoft.com/en-us/vcpkg/get_started/overview).
This issue contains many aspect and:
- must answer the question : Should we move to msys2 or vcpkg or stay on chocolatey+MSVC?
- must provide a new toolchain documentation
- must provide a new docker image for CI
- (if possible) must provide a new documentation on how to use the docker image to develop on windows without installing software
See:
- [msys2 description](https://www.msys2.org/docs/what-is-msys2/)
- [project that use msys2](https://www.msys2.org/docs/who-is-using-msys2/), to check how they use it, what's the impact on their toolchain, and how they manage their CI (e.g., [inkscape](https://wiki.inkscape.org/wiki/Compiling_Inkscape_on_Windows_with_MSYS2) and [inkscape CI on gitlab.com](https://gitlab.com/inkscape/inkscape/-/raw/master/buildtools/msys2installdeps.sh)).
- [dockerization tentative for msys2](https://github.com/Amitie10g/docker-msys2)
If MSys2 is adopted:
- All dependencies library should be available (xerces-c,...), including some that are not directly used in CCE but are known to be used/supported in CEPs (e.g., opencv, SDL2,...)
- MSC++ will not be used as the default compiler on windows (subsidiary question: does it have other side effects? Any impact on the future python binding?)
- that reinforce the recommendation of vscode as an ide on all platform (see #181), including windows [mingw for vscode documentation](https://code.visualstudio.com/docs/cpp/config-mingw#_adding-additional-cc-settings)
**Additional questions**
- impact CI performance (subsidiary question: is there a way to optimize the docker handling by windows? Is win11 better than win10 for handling containerized toolchain?)
- can the window docker image be used to build and run CEPs by CEP developers. That would certainly ease the setup process and will have zero impact on the developer installation. Iit is probably easy to build a CEP from vscode + devcontainer using the window docker image, but it might be harder/not possible/not efficient to run `camitk-imp` from the docker container → that remain to be tested!
- :warning: **CMake macros.** Some CamiTK CMake code (configuration and CI) depends on checking if the compiler is MSVC. There might be some problems to fix there as well if changing to mingw64.
- using mingw64 might automatically close #64 (declimport/declexport). But then another decision will have to be taken about what to do with legacy code (remove the macros for managing declimport/declexport or not). And also a decision has to be taken for using the CMake property from now on...
## Acceptance tests
- [ ] Internal document to explain the decision
- [ ] window docker image for CI (updated or renewed)
- [ ] re-generate the CamiTK5.2 package using the new image (to test the release process for future release)
- [ ] update website setup documentation
- [ ] update [support policy web page](https://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/DevTeam/camitk-website/-/blob/master/content/en/docs/advanced%20topics/developers/support%20policy.md)
- [ ] in the `develop` branch check `CMakeLists.txt` for minimal version and check if update is required
- [ ] in the `develop` branch move version requirements for the tests (VTK and ITK version) and update test file if required. For instance : `component-stl-level3-2`, `vtkimage`...
- [ ] update release documentation to add a step that uses the Windows toolchain and solve the compiler/linker warnings before adding the release tag (same as the clang)
**Note** Use tag `:2025` for the image instead of `5.3` (change of docker image naming convention)Emmanuel PromayonEmmanuel Promayonhttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/180Simplify CamiTKVersion.h management2024-02-23T11:20:59+01:00Emmanuel PromayonSimplify CamiTKVersion.h management| | |
|--|--|
| **As a** | CamiTK developer and packager |
| **I would like to** | simplify the release and packaging process |
| **So that** | it would be easier to publish and package a new version |
| **Epic/Topics** | release managem...| | |
|--|--|
| **As a** | CamiTK developer and packager |
| **I would like to** | simplify the release and packaging process |
| **So that** | it would be easier to publish and package a new version |
| **Epic/Topics** | release management |
## Description / Overview
This point for this issue is:
- gather explanation about/rationale behind the existence of `CamiTKVersion.h` and `CamiTKVersion.h.in` file
- explain some consequence of the existence of this file
- work on how it can be simplified
## Hints
`CamiTKVersion.h` contains static information about the version number, debug postfix and `libDir`.
This file generates some complicated maneuvers during release management and packaging (see below).
### Some background on plugins
- CamiTK has a core library and uses plugins to add I/O (components), processing (actions) and viewer functionalities
- the plugins are made available using .so stored in "camitk repository", a directory that has a specific structure with subdirectories to sort plugins depending on their nature (actions, components, viewers)
- at run time, the core library looks into different paths for locating the existing camitk repositories (working directory, user installed, locally installed, or globally installed) in order to dynamically load all the available plugins.
- The libDir variable is used to check the camitk repository paths, that should all be ending with "some/path/" + libDir + "/camitk-x.y" (where x.y are major.minor camitk version numbers).
- The CamiTKVersion.h header file is used to specify this statically.
- On the upstream develop branch, libDir is generated at configure time by CMake, using the CMAKE_INSTALL_LIBDIR variable which is either set to "lib/ARCH" (if CMAKE_INSTALL_PATH is set to "/usr") or to just "lib/" (if CMAKE_INSTALL_PATH is empty).
- on the upstream master branch (the stable version, used to generate the tar ball), this is fixed to "lib". **TODO: describe rationale behind this**
### Generated burden
It might not be the best way to proceed, it is a bit complicated... That's what we came up with at the time (pre 2011) to answer to the following support constraints :
- multiple os,
- multiple camitk repositories,
- and multiple build situation (inbuild, sdk, install, cep dev)
It looks more like technical debt and could probably be simplified as it impact
- the release management process
- the packaging process (s.g. during 5.2 release `CamiTKVersion.h` was different on debian salsa master and in the upstream tarball), see also d/r and the line that uses `sed` to correct the file on debian...
### Note on `libDir` introduction in CamiTK version
`libDir` in CamiTKVersion was introduced #109 and #117 (commit de1794622009c4edd6cf4220773b61dbd644c37e) in order to support gentoo, and was later modified to take into account more situations:
- lib (default)
- lib64 (used on some Linux/platform)
- lib/<multiarch-tuple> (on Debian)
### Fixing this issue
Fixing this issue can be done either by
- option 1: confirming that a static `CamiTKVersion.h` (part of all of it) is required in `master`
- option 2: removing `CamiTKVersion.h` in master and generated release version tarball
## Acceptance tests
- [ ] option 1: better documentation to explain why a static `CamiTKVersion.h` is required
- [ ] option 2: a branch fixing this issue is merged (therefore CI passed)
- [ ] option 2: successful debian packaging process test
## Track
## Misc
- Automatic subscription of issue creator:https://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/169add dbus connection2023-10-29T13:49:12+01:00Emmanuel Promayonadd dbus connection## About you
CamiTK dev
## Product
CamiTK Core / Application
## Overview
Issue #168 was not detected during configure/make/test as it is not possible to set a test where an application that starts a user interaction loop would be ru...## About you
CamiTK dev
## Product
CamiTK Core / Application
## Overview
Issue #168 was not detected during configure/make/test as it is not possible to set a test where an application that starts a user interaction loop would be run and stopped automatically after a while. For example, in the case of `camitk-fancy` that would have allowed for a simple start and exit. In the presence of a bug similar to #168, the test would then have failed.
A possible way of offering extended testing for application would be to add the possibility for any CamiTK application to listen to dbus messages.
- it would then be possible to send message from outside the application (e.g. a shell, a test script or program...) such as "run action `Quit`".
- it would also add the **great** advantage of opening a whole lot of testing and automation. For instance by sending message analog to state in the action state machine (e.g. by sending XML/json message containing the action to apply and its parameter).
## Relevant logs and/or screenshots
### Adding dbus message support in CamiTK::Application
For instance by using:
```cpp
QDBusConnection::sessionBus().connect(QString(), QString(), "camitk.action", "apply", this, SLOT(applyActionFromDBus(QString)));
...
void Application::applyActionFromDBus(const QString &message) {
if(message=="...") {
...
}
}
```
### From the test application
```cpp
QProcess myProcess;
myProcess.start("camitk-fancy", "");
if (!myProcess.waitForStarted())
return false;
QDBusMessage msg = QDBusMessage::createSignal("/", "camitk.action", "apply");
message="Quit"
QDBusConnection::sessionBus().send(msg);
if (!myProcess.waitForFinished())
return false;
```
**Note**
DBus is supported on Linux desktops by default. A [windows port exists](https://www.freedesktop.org/wiki/Software/dbus/#download) but this need further checks.
### dbus not allowed by default
For security reason, the default behaviour should be _not_ to listen to DBus, and flag `--dbus` should be added to the arguments to enable the feature in the application.
### See also
[KDE doc for creating dbus interface](https://develop.kde.org/docs/features/d-bus/creating_dbus_interfaces/)
---