cmake --install <b> --prefix <p> broken in 1.2.0 #555

New Issue

claunia · 2026-01-29T20:45:45Z

claunia commented

2026-01-29 20:45:45 +00:00

Originally created by @vszakats on GitHub (Oct 31, 2025).

When installing man pages, the installation directory is set to its
full, final, absolute path (CMAKE_INSTALL_FULL_MANDIR). This makes
the build ignore a --prefix set at install time, and fail:

$ cmake --install bld --prefix my/pfx
-- Install configuration: "Release"
CMake Error at bld/cmake_install.cmake:89 (file):
  file cannot create directory: /usr/share/man/man3.  Maybe need
  administrative privileges.

Live example: https://github.com/curl/curl-for-win/actions/runs/18853487748/job/53795465550

In other envs, or when run with sudo, it may overwrite system man pages
with the one from this build.

The CMake manual says this about CMAKE_INSTALL_FULL_* variables:
"These variables shouldn't be used in install() commands as they do
not work with the cmake --install command's --prefix option, or with
the cpack installer generators."
Ref: https://cmake.org/cmake/help/v4.2/module/GNUInstallDirs.html

The commit leading up to this fixed and earlier wrong variable:
cff5803216 #1084

A correct fix is to use the recommended variable CMAKE_INSTALL_MANDIR
instead of its _FULL_ variant (as done already for LIBDIR, INCLUDEDIR).

--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -384,11 +384,11 @@ endif()  # BROTLI_BUNDLED_MODE
 
 if (BROTLI_BUILD_TOOLS)
   install(FILES "docs/brotli.1"
-    DESTINATION "${CMAKE_INSTALL_FULL_MANDIR}/man1")
+    DESTINATION "${CMAKE_INSTALL_MANDIR}/man1")
 endif()
 
 install(FILES docs/constants.h.3 docs/decode.h.3 docs/encode.h.3 docs/types.h.3
-  DESTINATION "${CMAKE_INSTALL_FULL_MANDIR}/man3")
+  DESTINATION "${CMAKE_INSTALL_MANDIR}/man3")
 
 if (ENABLE_COVERAGE STREQUAL "yes")
   setup_target_for_coverage(coverage test coverage)

Confirmed working: https://github.com/curl/curl-for-win/actions/runs/18853837259/job/53796629171

Closing the PR in favor of this report.

Originally created by @vszakats on GitHub (Oct 31, 2025). When installing man pages, the installation directory is set to its full, final, absolute path (`CMAKE_INSTALL_FULL_MANDIR`). This makes the build ignore a `--prefix` set at install time, and fail: ```console $ cmake --install bld --prefix my/pfx -- Install configuration: "Release" CMake Error at bld/cmake_install.cmake:89 (file): file cannot create directory: /usr/share/man/man3. Maybe need administrative privileges. ``` Live example: https://github.com/curl/curl-for-win/actions/runs/18853487748/job/53795465550 In other envs, or when run with sudo, it may overwrite system man pages with the one from this build. The CMake manual says this about `CMAKE_INSTALL_FULL_*` variables: "These variables shouldn't be used in install() commands as they do not work with the cmake --install command's --prefix option, or with the cpack installer generators." Ref: https://cmake.org/cmake/help/v4.2/module/GNUInstallDirs.html The commit leading up to this fixed and earlier wrong variable: cff58032160406c170a3dc319ad6e7b288cafcc0 #1084 A correct fix is to use the recommended variable `CMAKE_INSTALL_MANDIR` instead of its `_FULL_` variant (as done already for `LIBDIR`, `INCLUDEDIR`). ```diff --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -384,11 +384,11 @@ endif() # BROTLI_BUNDLED_MODE if (BROTLI_BUILD_TOOLS) install(FILES "docs/brotli.1" - DESTINATION "${CMAKE_INSTALL_FULL_MANDIR}/man1") + DESTINATION "${CMAKE_INSTALL_MANDIR}/man1") endif() install(FILES docs/constants.h.3 docs/decode.h.3 docs/encode.h.3 docs/types.h.3 - DESTINATION "${CMAKE_INSTALL_FULL_MANDIR}/man3") + DESTINATION "${CMAKE_INSTALL_MANDIR}/man3") if (ENABLE_COVERAGE STREQUAL "yes") setup_target_for_coverage(coverage test coverage) ``` Confirmed working: https://github.com/curl/curl-for-win/actions/runs/18853837259/job/53796629171 Closing the [PR](#1367) in favor of this report.

claunia closed this issue

2026-01-29 20:45:45 +00:00

claunia commented

2026-01-29 20:45:46 +00:00

@eustas commented on GitHub (Nov 7, 2025):

Thanks for investigation and explanation. Will fix soon.

@eustas commented on GitHub (Nov 7, 2025): Thanks for investigation and explanation. Will fix soon.

claunia commented

2026-01-29 20:45:46 +00:00

@vszakats commented on GitHub (Nov 24, 2025):

Seems to be fixed in #1384. No credits, no reference to this report.

@vszakats commented on GitHub (Nov 24, 2025): Seems to be fixed in #1384. No credits, no reference to this report.