Fixed paths

[OgreTransporter]

The file cmake/ChronoConfig.cmake.in contains numerous hard-coded absolute paths. For example:

chrono/cmake/ChronoConfig.cmake.in

Line 271 in d6270e5

set(Eigen3_DIR "@Eigen3_DIR@" CACHE PATH "Path to Eigen3 config file (should contain the \"Eigen3Config.cmake\" file")

I don’t think this is a good approach, because when I transfer the library to another computer, the paths are usually incorrect. After the build, ChronoConfig.cmake then contains, for example:

set(Eigen3_DIR "E:/workspace/ProjectChrono/deps/Eigen/share/eigen3/cmake" CACHE PATH "Path to Eigen3 config file (should contain the \"Eigen3Config.cmake\" file")

This applies not only to Eigen3 but also to the other dependencies.

[rserban]

All of these CMake variables are cached. They are initialized to the values that were used during the Chrono configuration (on the machine used to build the code). But you can change them (and you likely should change them if moving the installation to a different machine). Beware that some of these variables are also marked as advanced (so also check the advanced CMake variables when using the Chrono project configuration script).

One other comment: I am not exactly sure how you "transfer the library to another computer", but judging by your mention of Eigen3_DIR I suspect you are manually moving things from the build directory. Is that is the case, I suggest you instead install Chrono on the build machine and then transfer the installation directory. Of course, when using the Chrono installation on a different machine, you will still have to adjust (if and as needed) various variables as above.

[OgreTransporter]

I understand how these cached variables are currently intended to work, but the core issue is not about user workflow or copying the build directory. The problem is that the generated ChronoConfig.cmake contains absolute paths from the build machine, which makes the installed Chrono package non‑relocatable. This contradicts CMake’s guidelines for installable packages.

To illustrate the issue, here is a concrete example:

Machine A (Desktop) – Build and Install

Chrono and its dependencies are built on drive E::

Eigen3_DIR "E:/workspace/ProjectChrono/deps/Eigen/share/eigen3/cmake"

Chrono is then installed to:

E:/workspace/ProjectChrono/install

Everything works correctly on this machine.

Machine B (Laptop) – Using the Installed Package

The installed Chrono directory is copied to:

D:/dev/SDKs/ProjectChrono

Eigen is installed separately under:

D:/dev/SDKs/Eigen

However, the installed ChronoConfig.cmake still contains the hard‑coded path from the desktop machine:

set(Eigen3_DIR "E:/workspace/ProjectChrono/deps/Eigen/share/eigen3/cmake")

This path:

• points to a drive that does not exist on the laptop
• refers to the build tree of the desktop machine
• does not match the actual Eigen installation on the laptop

As a result, find_package(Chrono) fails unless the user manually overrides internal variables. This happens even though Chrono was properly installed, not copied from the build directory.

Why this is a design issue

CMake’s documentation explicitly states:

“A relocatable package must not reference absolute paths of files on the machine where the package is built that will not exist on the machines where the package may be installed.”
CMake Packages Manual – “Creating Relocatable Packages”

The current approach using configure_file() embeds build‑time paths directly into the installed package. This makes Chrono:

• non‑portable
• non‑relocatable
• difficult to distribute via package managers
• fragile in CI/CD and container environments
• dependent on the original build machine’s directory layout

How CMake packages normally solve this

Modern CMake packages use:

• configure_package_config_file()
• @PACKAGE_INIT@
• find_dependency()

This ensures that the installed package:

• does not contain absolute build paths
• finds dependencies on the target system, not the build system
• can be moved to any directory or machine without breaking

For example:

@PACKAGE_INIT@
include(CMakeFindDependencyMacro)
find_dependency(Eigen3 REQUIRED)

This produces a fully relocatable installation that works out of the box.

Summary

The issue is not about adjusting cached variables after installation, but about the fact that the installed Chrono package contains absolute paths from the build environment. This prevents Chrono from being used as a relocatable CMake package and causes failures when the installation is moved to a different machine or directory layout.

I hope this clarifies why the current behavior leads to practical problems and why adopting the standard CMake mechanisms for relocatable packages would significantly improve Chrono’s portability and integration.