* Select RHEL8 vcpkg-configuration.json via CMake instead of renaming the tracked file
RHEL8 CI jobs previously ran 'cp vcpkg-configuration-rhel8.json vcpkg-configuration.json'
before configuring, temporarily overwriting the tracked default configuration
in the checkout. The vcpkg toolchain file only defaults VCPKG_MANIFEST_DIR to
CMAKE_SOURCE_DIR when it is not already defined, and reads it while processing
project(), so setting VCPKG_MANIFEST_DIR earlier -- before project() -- lets
vcpkg read a different vcpkg-configuration.json without ever touching the
tracked file.
Add a RESINSIGHT_VCPKG_PROFILE cache variable, implemented in the new
cmake/ResInsightVcpkgProfile.cmake (included from the root CMakeLists.txt
before project(), which is required for VCPKG_MANIFEST_DIR to take effect).
When set (e.g. to 'rhel8'), it copies vcpkg.json and
vcpkg-configuration-<profile>.json into a profile-specific directory under
the build tree and points VCPKG_MANIFEST_DIR there. The copy is regenerated on
every configure, so it can never drift from the root vcpkg.json.
overlay-ports/overlay-triplets entries (e.g. 'ThirdParty/vcpkg-overlay-ports')
are resolved by vcpkg relative to the directory vcpkg-configuration.json lives
in, so repo-relative 'ThirdParty/...' paths are rewritten to absolute paths
right after the copy is generated, keeping them valid from the new location.
Update the RHEL8 workflows and Dockerfile.rhel8 build-warmup stage to pass
-DRESINSIGHT_VCPKG_PROFILE=rhel8 instead of the cp step, and update
vcpkg-readme.md to describe the new mechanism.
* #14733 Use x64-linux-release vcpkg triplet explicitly in RHEL8 CI
The RHEL8 CI workflows and the Docker image's warmup/vcpkg-cache stages
did not set VCPKG_TARGET_TRIPLET/VCPKG_HOST_TRIPLET, so vcpkg fell back
to its plain x64-linux default triplet, which builds both debug and
release variants of every dependency even though the CI build is
Release-only. Set both to x64-linux-release consistently across the
image's vcpkg install, the warmup CMake configure, and the two
consuming workflows so the baked binary cache and the CI configure use
matching ABI hashes and skip the unused debug builds.
libstdc++ defines __cpp_lib_stacktrace from GCC 13 on, but the implementation
lives in libstdc++exp, which some distributions do not ship (Red Hat's
gcc-toolset among them). The header-only feature test then reports the feature
as present and the link fails with undefined references to
std::__stacktrace_impl::_S_current.
Add cmake/StdStacktrace.cmake, which probes the feature by actually linking:
first with no extra library, then with stdc++exp. The result selects the link
library through RESINSIGHT_STACKTRACE_LIBRARIES, or defines
RIA_HAS_STD_STACKTRACE=0 project-wide when neither links, so the crash handler
compiles out its stack-trace capture and logs the signal only.
RiaMainTools.cpp and RiaOpenTelemetryManager.h now honour a
RIA_HAS_STD_STACKTRACE definition from the build system and only include
<stacktrace> when the feature is enabled.
Follow-up to #14045.
GCC's -Wfree-nonheap-object false-positives on inlined std::vector copies
(GCC PR 104475), breaking -Werror builds with GCC 15 on Ubuntu 26.04. Keep
the warning visible but do not let it fail the build.
AutoVcpkg assumed that the bootstrap file was in the root project
folder, and not in a cmake subfolder.
Note: It is not correct to use ${CMAKE_CURRENT_LIST_DIR} since this is
inside a function and whould still refer to the folder of the calling
file. The more elegant solution would be to use
${CMAKE_CURRENT_FUNCTION_LIST_DIR}, but that is not available until
CMake 3.17.
Magne Sjaastad
magnesj
Kristian Bendiksen
Eirik Marthinsen
Gaute LindkvistandRuben Thoms