Simplify 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 management |
Description / Overview
This point for this issue is:
- gather explanation about/rationale behind the existence of
CamiTKVersion.h
andCamiTKVersion.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 usessed
to correct the file on debian...
libDir
introduction in CamiTK version
Note on libDir
in CamiTKVersion was introduced #109 (closed) and #117 (closed) (commit de179462) in order to support gentoo, and was later modified to take into account more situations:
- lib (default)
- lib64 (used on some Linux/platform)
- lib/ (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 inmaster
- 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:
Edited by Emmanuel Promayon