Hello Sébastien,
Thank you for your response. Sorry for the delay in my response, and sorry for the long reply in advance, but I think it is necessary to clarify what I was trying to do.
I understand your concern about introducing potential build issues on other GNU/Linux distributions. However, I would like to clarify that the patch I proposed does not alter the detection mechanism for existing setups. On the contrary, it enhances portability and robustness by extending the search paths to include patterns commonly used in non-FHS-compliant distributions such as Nix.
Currently, the Dicomweb plugin only checks for the Orthanc Framework headers in 3 hardcoded locations:
/usr/include/orthanc-framework
/usr/local/include/orthanc-framework
${ORTHANC_FRAMEWORK_ROOT}
While this works well on traditional Linux systems, it is incompatible with Nix, where system-wide paths like /usr
are not used. As you may know, in the Nix ecosystem, dependencies are fully isolated, and all paths are explicitly provided via build flags.
To follow your current design, I used the recommended ORTHANC_FRAMEWORK_ROOT
flag:
cmakeFlags = [
# ...
"-DORTHANC_FRAMEWORK_ROOT=${orthanc.framework}"
];
However, this approach fails because the plugin expects the headers to be located directly under ${ORTHANC_FRAMEWORK_ROOT}
— whereas, in reality, they are installed (by the Orthanc Framework itself) under ${ORTHANC_FRAMEWORK_ROOT}/include/orthanc-framework
, as defined in the upstream build logic (orthanc: 980ab5ed1f59 OrthancFramework/SharedLibrary/CMakeLists.txt).
To address this mismatch, I initially proposed the following patch:
find_path(ORTHANC_FRAMEWORK_INCLUDE_DIR OrthancFramework.h
/usr/
/usr/local/
${ORTHANC_FRAMEWORK_ROOT}
PATH_SUFFIXES include include/orthanc-framework
)
This usage is fully compliant with CMake’s find_path()
mechanism (find_path — CMake 4.0.1 Documentation), and it preserves the existing logic while adding flexibility. In practice, it expands the search space by computing the Cartesian product of the base paths and suffixes, resulting in combinations such as:
/usr
/usr/local
${ORTHANC_FRAMEWORK_ROOT}
/usr/include
/usr/local/include
${ORTHANC_FRAMEWORK_ROOT}/include
/usr/include/orthanc-framework
/usr/local/include/orthanc-framework
${ORTHANC_FRAMEWORK_ROOT}/include/orthanc-framework
This makes the detection mechanism more resilient and future-proof, especially for distributions with isolated include trees like Nix.
Note: The inclusion of include
in the PATH_SUFFIXES
list was an oversight on my part and can be safely removed.
That said, if the use of PATH_SUFFIXES
is not desirable for upstream, I would like to propose the following, more explicit alternative:
Option 2: Add the expected path directly
find_path(ORTHANC_FRAMEWORK_INCLUDE_DIR OrthancFramework.h
/usr/include/orthanc-framework
/usr/local/include/orthanc-framework
${ORTHANC_FRAMEWORK_ROOT}/include/orthanc-framework
)
This avoids abstractions while remaining aligned with the directory structure generated by the Orthanc Framework’s install step.
Ultimately, my goal is to avoid hardcoding fragile assumptions about directory layouts on the packaging side. Doing so would tightly couple Nix packages to internal details of your build system, which could change in the future.
Merci 