@jodogne Here’s the patch I made for orthanc-dicomweb: https://github.com/NixOS/nixpkgs/blob/master/pkgs/by-name/or/orthanc-plugin-dicomweb/fix-orthanc-framework-headers-detection.patch (I was not able to make a link, and the post has been flagged).
I guess I’ll find the same issue on other plugins, but I haven’t yet tried to package another plugin. I quickly tried orthanc-python, but it was failing to detect the Python package, I’ll give it another try on another day.
Hello,
Thanks for your patch, however it might cause build issues on other GNU/Linux distributions. I think it is better to leave such changes to the package maintainers of each system to avoid potential problems down the line.
Regards,
Sébastien-
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-frameworkThis 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:
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 
Hello,
Thanks for your detailed analysis, unfortunately your changes would disrupt some assumptions for non-Linux distributions, in particular if linking a plugin against the Orthanc framework on Windows or if targeting WebAssembly (as in the Stone Web viewer). The ORTHANC_FRAMEWORK_ROOT is indeed defined as the folder containing the OrthancFramework.h file, which may not have the include/orthanc-framework prefix.
From my perspective, couldn’t your Nix package use:
cmakeFlags = [
# ...
"-DORTHANC_FRAMEWORK_ROOT=${orthanc.framework}/include/orthanc-framework"
];
Regards,
Sébastien-
Hello Sébastien,
Thank you for your reply and for clarifying your concerns. And no problem at all, I think it was important to clarify, but it looks like I failed to make my point 
While I understand the intention behind keeping ORTHANC_FRAMEWORK_ROOT narrowly defined, I would argue that the current detection logic makes strong assumptions about how the Orthanc Framework is installed. Unfortunately, these assumptions do not hold on all platforms.
Your suggestion to set:
cmakeFlags = [
# ...
"-DORTHANC_FRAMEWORK_ROOT=${orthanc.framework}/include/orthanc-framework"
];
is technically valid today, but it introduces an implicit contract between Orthanc and downstream packagers. If that directory layout changes in the future (for example, moving to share/, renaming the subfolder, or restructuring the install tree). downstream packages would need to be updated accordingly. This kind of tight coupling contradicts the principles of reproducible builds and long-term maintainability.
In my view, the confusion stems from the overloaded semantics of the ORTHANC_FRAMEWORK_ROOT variable. Intuitively, this flag should refer to the root of the orthanc-framework installation, while a separate flag such as ORTHANC_FRAMEWORK_INCLUDE_DIR could explicitly point to the actual location of the headers.
To summarise, what I am trying to avoid is hardcoding the path include/orthanc-framework in the Nix expression. I believe it should be the responsibility of Orthanc’s build system to discover this automatically, using CMake’s standard mechanisms.
If you have another idea for resolving this gracefully, I would be very happy to hear it. Otherwise, I will continue maintaining this patch downstream in Nixpkgs.
In advamce, thank you for your time on this!
I understand the suggestion, but I need to take a pragmatic approach here. Making a breaking change at the core of the build infrastructure would require a major amount of effort and could lead to considerable disruption across the Orthanc community, without bringing any added value. Our resources are limited, so we need to prioritize practical solutions over ideal ones when it comes to packaging. From my perspective as BDFL, if an issue can be easily addressed with a one-line change in a downstream package, that’s where it’s best handled.
Regards,
Sébastien-
Okidocky, no problem I fully understand.
I’ll use your suggestion for the time being then.
Thank you again!!!
Hello all,
I implemented the suggestion in Nix at orthanc-plugin-dicomweb: remove custom patch, cleanup by drupol · Pull Request #400396 · NixOS/nixpkgs · GitHub
Happy Easter!