[keyple-dev] Keyple C++ dependencies

[Charles HUET <charles.huet@xxxxxxxxxxxxxxxx>]

Hi,

As some of you may know, I have been contributing small improvements to the keyple C++ codebase, most notably on the build system side of things.

I want to talk about the general direction and goal of the CMake files, to ensure I can contribute in the most efficient way to the Keyple C++ project, and make a proposition about where it should head, in my opinion.

Since the current best way to retrieve all of keyple C++ is to use the cpp-meta repository, which is currently unable to differentiate versions for the different components, it is difficult to upgrade a single part of keyple.

Ideally, cloning the demos repository should be enough to get a simple build started, with an automatic and transparent dependency management (i.e. the demos would declare their dependencies and version, and those would be fetched transparently to the user).

Since C++ inherently  differs from Java, specifying different versions for a single dependency (e.g. Keyple Utils library) can cause issues depending on the linkage type and binary compatibility.

For instance if keyplecardgenericcpplib​ and UseCase4_ScheduledSelection were to link dynamically ​to binary compatible but differently versions of keypleutilcpplib​, only one version would be used in the final executable due to symbol name collision. This could potentially cause issues if keyplecardgenericcpplib​​ was depending on a different behavior from keypleutilcpplib​ than the one UseCase4_ScheduledSelection is expecting (e.g. a function was modified to return a different value in a certain case).

This also raises the issue of binary compatibility, but I will assume semantic versioning is well used, and the rules to keep C++ code binary compatible weel understood 🙂

To ensure correct behavior, either static linking should be preferred, or a stricter dependency management put into place, with a reliance on transitive dependencies.

Both have benefits, but changing the linking type is something that can be easily modified by the end user, while modifying the dependency management would have beneficial results on the potential contributors to Keyple C++.

To conclude, I propose modifying the Keyple C++ buildsystem to:

• use transitive dependencies
• explicitly link against dependencies (i.e. when including a file from another library, link against it)
  
• fetch keyple dependencies instead of expecting them to be present
  

This can be done in multiple phases :

1. modernize the CMake to exclusively use targets
2. ensure there are independent builds of each component, to ensure each component declares its dependencies correctly
3. check that there are no redundant links, once every target correctly declares its dependencies
4. fetch the dependencies of each target in its CMakeLists

I have started on phase 1, but my PRs have been waiting for quite some time now, so I will list them here:

• https://github.com/calypsonet/calypsonet-terminal-card-cpp-api/pull/2
• https://github.com/calypsonet/calypsonet-terminal-reader-cpp-api/pull/3
• https://github.com/eclipse/keyple-card-calypso-cpp-lib/pull/3 (this one does not show up on the dashboard, strangely)

Thanks for reading,

Best