Skip to content

Make ImportRoadrunnerAndDependencies.cmake usable by consumers - #1432

Open
matthiaskoenig wants to merge 1 commit into
sys-bio:developfrom
matthiaskoenig:fix/import-roadrunner-cmake-consumers
Open

matthiaskoenig wants to merge 1 commit into
sys-bio:developfrom
matthiaskoenig:fix/import-roadrunner-cmake-consumers

Conversation

@matthiaskoenig

Copy link
Copy Markdown
Collaborator

Fixes the two code level causes in #1431, which together make the installed
ImportRoadrunnerAndDependencies.cmake unusable from another C++ project on Linux.

Changes

find_package(zlib ...) becomes find_package(ZLIB ... COMPONENTS static).
The dependency tree ships ZLIBConfig.cmake, so the lowercase name only resolved on a case
insensitive file system. This is the same call roadrunner's own build makes at CMakeLists.txt:403.

The helper now sets up the search paths its find_package calls need, instead of assuming the
consuming project has already done it. It derives the roadrunner prefix and the cmake directory,
where FindLLVM.cmake and the roadrunner package files are installed, from its own location, and
adds the dependency config directories (<deps>/cmake, <deps>/lib*/cmake, <deps>/lib*/cmake/Poco)
the way CMakeLists.txt:380 does for roadrunner's own build. RR_DEPENDENCIES_INSTALL_PREFIX and
LLVM_INSTALL_PREFIX default to the roadrunner install tree. Consuming a roadrunner install is now:

set(LLVM_INSTALL_PREFIX "/path/to/llvm-23.1.4")
set(RR_DEPENDENCIES_INSTALL_PREFIX "/path/to/libroadrunner-deps")
include("/path/to/install/lib/cmake/ImportRoadrunnerAndDependencies.cmake")
target_link_libraries(your_target PRIVATE roadrunner-static::roadrunner-static)

A new documentation section, "Using RoadRunner from another C++ project", records what a consumer
has to know: link against the install tree and not the build tree, keep the LLVM and dependency
trees where they were because the exported targets name those archives by absolute path, compile
with C++17 or later and with RTTI enabled, Poco::Foundation pulls the compile up to C++20 anyway,
and a lib64 dependency tree is not copied into the install tree so RR_DEPENDENCIES_INSTALL_PREFIX
has to be passed.

Verification

Built roadrunner develop on Ubuntu 24.04 x86_64 against libroadrunner-deps v2.3.9
(manylinux_2_28) and llvm-23.1.4-ubuntu-24, then configured, built and ran a separate consumer
project against the install tree: it imports through the helper, links
roadrunner-static::roadrunner-static and simulates dx/dt = -k*x, giving x(1) = 0.367879 against
exp(-1) = 0.367879. The resulting binary needs only libm, libstdc++, libgcc_s and libc. Before this
change the same project stopped at the zlib line, and with that line fixed by hand it stopped at
sbml-static.

The roadrunner build itself does not include this file, so nothing in the build or the test suites
is affected. For the record, the full suites on that build are green: 3505 C++ tests and 15 Python
tests.

Not addressed here: the third cause in #1431, install(DIRECTORY "${RR_DEPENDENCIES_INSTALL_PREFIX}/lib")
at CMakeLists.txt:506 ignoring lib64, which is why a lib64 dependency tree has to be kept
around. That one changes what the published artifact contains, so it needs a decision rather than a
patch.

find_package(zlib CONFIG REQUIRED) only resolves on a case insensitive file
system. The dependency tree ships ZLIBConfig.cmake and roadrunner's own build
asks for it as find_package(ZLIB CONFIG REQUIRED COMPONENTS static), so
including the helper from another project failed on Linux at that line.

The helper also assumed the consuming project had already put the dependency
config directories on CMAKE_PREFIX_PATH and the install tree's cmake directory
on CMAKE_MODULE_PATH, which is something only roadrunner's own CMakeLists does.
Without those paths sbml-static, PocoFoundation, SUNDIALS and FindLLVM are not
found either. It now derives both from its own location and from
RR_DEPENDENCIES_INSTALL_PREFIX, so a consuming project points at the trees and
includes the file.

Documents the consuming side in the installation docs: which tree to link
against, that the LLVM and dependency trees have to stay in place, the C++17 and
RTTI requirement, and that a lib64 dependency tree is not copied into the
install tree.

Part of sys-bio#1431. The third cause reported there, install(DIRECTORY
"${RR_DEPENDENCIES_INSTALL_PREFIX}/lib") ignoring lib64, is a decision about the
artifact layout and is left out of this change.
@matthiaskoenig

Copy link
Copy Markdown
Collaborator Author

The documentation section added here points at scripts/link-example, which #1433 adds. If this PR is merged on its own, that one sentence should be dropped.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant