cmake (> 4.0) support and install targets

[brunodonassolo]

Hello,

Following the question at: https://community.developers.refinitiv.com/discussion/132623/sdk-compatibility-with-cmake-version-4-0.

When compiling the SDK (both github and release from the developer portal) with cmake version (> 4.0), we have the following error:

  Compatibility with CMake < 3.5 has been removed from CMake.

  Update the VERSION argument <min> value.  Or, use the <min>...<max> syntax
  to tell CMake that the project requires at least <min> but has been updated
  to work with policies introduced by <max> or earlier.

  Or, add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to try configuring anyway.


-- Configuring incomplete, errors occurred!

The workaround setting the environment variable (export CMAKE_POLICY_VERSION_MINIMUM=3.5) seems to work, but the current setup is not suitable for automated builds for many reasons: environment variables, download dependencies from the internet, no install targets.

In order to easily integrate with other build systems, would it be possible to:

1. Support natively cmake version (> 4.0)
2. Support installing the sdk lib and its dependencies. I see a similar request in issues cmake install targets #185, but looks like it was never prioritized.

Thank you!

[vlevendel]

@brunodonassolo, The GitHub version of code will require internet access for downloading dependencies. However, we do offer an archive of our code with pre-built libraries on Develop Portal ( check Downloads tab for any given API flavor) which includes all the dependencies: please download the platform specific archive if using C/C++ as well as the BinaryPack archive. Compatibility with pre-built libraries will depend on your platform: please check our READMEs.

1. We will look into supporting cmake version 4.0 when all dependencies also support this version. Meanwhile there is the workaround you've referenced or you may use pre-built libraries from the archives I've mentioned above. We can also add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 into our scripting.

2. At this time, cmake install is not on our roadmap but does not imply that we won't consider it for a future release (support will be provided with cmake install targets #185 ).

[brunodonassolo]

Hi,

Thank you for the response. We are using the pre-built version from the Develop Portal in the current code. But even that version fails for the same reason (incompatible with cmake >4.0).

@brunodonassolo, The GitHub version of code will require internet access for downloading dependencies. However, we do offer an archive of our code with pre-built libraries on Develop Portal ( check Downloads tab for any given API flavor) which includes all the dependencies: please download the platform specific archive if using C/C++ as well as the BinaryPack archive. Compatibility with pre-built libraries will depend on your platform: please check our READMEs.

We are indeed using this version for this exact reason. However, the build is still part of single application since it's hard to list all the libraries needed during link phase. That's why having a way to install them as a separate library would simplify the workflow.

Meanwhile is it possible to have the list of files and their location in the build output so we can manually export them?

1. We will look into supporting cmake version 4.0 when all dependencies also support this version. Meanwhile there is the workaround you've referenced or you may use pre-built libraries from the archives I've mentioned above. We can also add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 into our scripting.

If you can add support in your current CMakeLists files it would be great. It would avoid hacking the build system with external environment variables (which isn't ideal considering build reproducibility).

Please let me know when this is added.

3. At this time, cmake install is not on our roadmap but does not imply that we won't consider it for a future release (support will be provided with cmake install targets #185 ).

Thank you, it would greatly simplify our workflow. Looking forward for it.

[vlevendel]

@brunodonassolo

Meanwhile is it possible to have the list of files and their location in the build output so we can manually export them?

To use our pre-build libs (static and shared are available), you need two things: libraries and include files. The installation guide has details; however below is an example.

Please let me know when this is added.

Will do. We're looking into updating our scripting to include -DCMAKE_POLICY_VERSION_MINIMUM=3.5 and intend to keep this issue open for that purpose or to support 4.X. Our recommendation, for the moment, is to use latest cmake 3.X available or the workaround you stated works fine for you.

---------------------------------Example
Here are relevant lists of libs/includes for a linux distribution:

Library locations:

ETA Libraries
Static: /Cpp-C/Eta/Libs//.a
Shared: /Cpp-C/Eta/Libs//.so

EMA Libraries:
Static: /Cpp-C/Ema/Libs//libema.a
Shared: /Cpp-C/Ema/Libs//Shared/

External Shared Libs:
/installdb/RHEL9_64_GCC1141/Debug/lib64/

Closed Source VACache and Multicast Libraries:
Static: /Cpp-C/Eta/Libs//
Shared: /Cpp-C/Eta/Libs//Shared/

Closed Source DACS library (for DACSLock, PEs):
/Cpp-C/Eta/Utils/Dacs/Libs//

Include locations:

ETA:
/Cpp-C/Eta/Include # include all sub directories as well when you copy this content
EMA:
/Cpp-C/Ema/Src/Include/ # include all sub directories as well when you copy this content; NOTE that Ema.h references all sub directories

Closed Source VACache and Multicast Libraries:
/Cpp-C/Eta/Include/Cache/rtr

Closed Source DACS:
/Cpp-C/Eta/Utils/Dacs/Include

[maxgawason]

Has any progress been made on including -DCMAKE_POLICY_VERSION_MINIMUM=3.5 or supporting 4.X? We are running into the same issue and would prefer to be using cmake 4.X without adding the workaround to our build.

[vlevendel]

@maxgawason We can only move minimum when all dependencies (zlib, etc.) also move to a higher version. We will continue to monitor for updates on all dependencies and address this as soon as it is feasible.