Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot cmake --install since 10.0.0 #3489

Closed
petrmanek opened this issue Jun 14, 2023 · 6 comments
Closed

Cannot cmake --install since 10.0.0 #3489

petrmanek opened this issue Jun 14, 2023 · 6 comments

Comments

@petrmanek
Copy link
Contributor

Ever since I upgraded to 10.0.0 I am experiencing issues running cmake install on my project. This appears in 10.0.0 as well as 8732ad8 (latest master), so I thought I would be a good idea to bring to your attention. Full disclosure, I am uncertain whether this is a bug on my end or yours -- one reason that leads me to believe this is of concern upstream is that my usage of fmtlib is conventional, so there are not really that many issues where things could be going wrong

I include fmtlib in my project as a git submodule, using the following directory tree:

├── build
├── CMakeLists.txt
└── lib
    ├── CMakeLists.txt
    └── fmt            <---- this is a git submodule

Then wire it up in cmake like so:

  1. My project's CMakeLists.txt includes lib/CMakeLists.txt
  2. The lib/CMakeLists.txt sets FMT_SHARED=ON
  3. Then lib/CMakeLists.txt includes lib/fmt/CMakeLists.txt
  4. fmtlib's CMakeLists.txt does its thing
  5. After that, lib/CMakeLists.txt specifies install(TARGETS fmt), so that the built version of fmtlib is shipped with the rest of my project.

At compilation- and runtime, everything works as expected. The issue appears when I attempt to install the project. I see the following message:

$ cmake --install .. --prefix $(pwd)                                                                                                                                                  
-- Install configuration: "Debug"
-- Installing: <path to repo redacted>/build/asd/lib/libfmtd.so.10.0.1
-- Installing: <path to repo redacted>/build/asd/lib/libfmtd.so.10
-- Set runtime path of "<path to repo redacted>/build/asd/lib/libfmtd.so.10.0.1" to "/usr/lib/<project name redacted>:/usr/lib64/<project name redacted>:$ORIGIN:$ORIGIN/../lib"
-- Installing: <path to repo redacted>/build/asd/lib/libfmtd.so
CMake Error at <path to repo redacted>/build/lib/cmake_install.cmake:99 (file):
  file INSTALL cannot find
  "<path to repo redacted>/lib/include/fmt/args.h": No such file
  or directory.
Call Stack (most recent call first):
  <path to repo redacted>/build/cmake_install.cmake:47 (include)

I see the same result on all Linux distributions (in CI we use Fedora, Ubuntu, Debian mostly), but not on macOS nor Windows. It does not matter what build type I select, I can confirm that the same behavior appears with RelWithDebInfo as well as Release.

The error message is correct in that the file <path to repo redacted>/lib/include/fmt/args.h truly does not exist. Instead, I suppose cmake should be looking for <path to repo redacted>/lib/fmt/include/fmt/args.h instead. Is there any reason for why would lib/fmt be reduced to just lib/ in the installation path like this?

I am of course happy to run any tests locally and report back. Thank you for any advice you can provide!

@petrmanek petrmanek changed the title Cannot cmake install since Cannot cmake --install since 10.0.0 Jun 14, 2023
@vitaut
Copy link
Contributor

vitaut commented Jun 14, 2023

I am not sure what might be causing this but if it worked previously I recommend bisecting to the change that introduced a problem.

@petrmanek
Copy link
Contributor Author

@vitaut Thanks, I am doing that now. Will let you know what I find.

Any ideas in the meantime are appreciated...

@petrmanek
Copy link
Contributor Author

@vitaut Finally had time to run a full bisect. The first commit where this behavior appears is ae25f79. I am currently on ce93a66, and am able to cmake --install my project without any issues.

It appears that the first of the two referenced commits set the PUBLIC_HEADER property of the cmake library target to a relative path w.r.t. fmtlib repository. I suspect that needs to be converted into a relative path w.r.t. the top-level repository, or an absolute path. I will try to run a little experiment and report back.

@petrmanek
Copy link
Contributor Author

Here is a patch that fixes the bug for me. I have simply created an auxiliary list for public headers, where I have turned each relative path into an absolute one. Verified to work with the first broken commit as well with the latest HEAD.

diff --git a/CMakeLists.txt b/CMakeLists.txt
index f2ea8ef5..cc740c45 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -250,9 +250,12 @@ target_include_directories(fmt ${FMT_SYSTEM_HEADERS_ATTRIBUTE} PUBLIC

 set(FMT_DEBUG_POSTFIX d CACHE STRING "Debug library postfix.")

+set(FMT_ABS_HEADERS "${FMT_HEADERS}")
+list(TRANSFORM FMT_ABS_HEADERS PREPEND ${PROJECT_SOURCE_DIR}/)
+
 set_target_properties(fmt PROPERTIES
   VERSION ${FMT_VERSION} SOVERSION ${CPACK_PACKAGE_VERSION_MAJOR}
-  PUBLIC_HEADER "${FMT_HEADERS}"
+  PUBLIC_HEADER "${FMT_ABS_HEADERS}"
   DEBUG_POSTFIX "${FMT_DEBUG_POSTFIX}")

 # Set FMT_LIB_NAME for pkg-config fmt.pc. We cannot use the OUTPUT_NAME target

@petrmanek
Copy link
Contributor Author

One last note: list(TRANSFORM <list> PREPEND <prefix>) is available from cmake v3.12 on, if that is of interest.

@vitaut
Copy link
Contributor

vitaut commented Jun 18, 2023

I think we should revert ae25f79 because it's not even clear what value it brings. A PR to do it will be welcome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants