As per title: multiple places in the code assume that INSTALL_{BIN,INCLUDE,LIB}_DIR are relative and yield broken output when they are absolute. That by itself would not be a problem, even if the comments are kind of fuzzy on whether these must or only should be relative (the way the code creates and populates ${PROJECT_NAME}_FULL_INSTALL_{BIN,INCLUDE,LIB}_DIR suggests the latter)—they are private to this build system after all. But if not set explicitly they get populated from the CMake-standard CMAKE_INSTALL_{BIN,INCLUDE,LIB}DIR, which definitely can be absolute. NixOS in particular passes absolute paths there whenever CMake is used and thereby exposes the problem.
A non-exhaustive list of occurrences of this problem is:
The pkg-config template in cmake/pkg-config.pc.in (the code nearby in cmake/pkg-config.cmake.in also looks suspect but I can’t really tell what it’s for);
The header template in cmake/ecbuild_config.h.in;
The clause handling ECBUILD_INSTALL_LIBRARY_HEADERS in cmake/ecbuild_install_project.cmake.
Jan Tojnar’s note linked above has more discussion of this problem in the general case. With the FULL variables already populated, all the tools to fix it here seem to be already in place, except they cannot be referenced from generic templates via @-expansion because their names depend on the name of the project (for reasons I don’t understand and so leave for you to examine).
As per title: multiple places in the code assume that
INSTALL_{BIN,INCLUDE,LIB}_DIRare relative and yield broken output when they are absolute. That by itself would not be a problem, even if the comments are kind of fuzzy on whether these must or only should be relative (the way the code creates and populates${PROJECT_NAME}_FULL_INSTALL_{BIN,INCLUDE,LIB}_DIRsuggests the latter)—they are private to this build system after all. But if not set explicitly they get populated from the CMake-standardCMAKE_INSTALL_{BIN,INCLUDE,LIB}DIR, which definitely can be absolute. NixOS in particular passes absolute paths there whenever CMake is used and thereby exposes the problem.A non-exhaustive list of occurrences of this problem is:
cmake/pkg-config.pc.in(the code nearby incmake/pkg-config.cmake.inalso looks suspect but I can’t really tell what it’s for);cmake/ecbuild_config.h.in;ECBUILD_INSTALL_LIBRARY_HEADERSincmake/ecbuild_install_project.cmake.Jan Tojnar’s note linked above has more discussion of this problem in the general case. With the
FULLvariables already populated, all the tools to fix it here seem to be already in place, except they cannot be referenced from generic templates via@-expansion because their names depend on the name of the project (for reasons I don’t understand and so leave for you to examine).