View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0015258CMakeCMakepublic2014-11-21 02:322015-05-04 09:05
ReporterArkadiusz Miskiewicz 
Assigned ToBrad King 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
Platformx86_64OSLinuxOS VersionPLD Th
Product Version 
Target VersionCMake 3.2Fixed in VersionCMake 3.2 
Summary0015258: 3.0.2-3.1rc2: _IMPORT_PREFIX always used even if absolute paths are in use - thus breaking build
Descriptioncmake 3.0.2 and 3.1rc2 shows this behaviour.

Anyway kde frameworks 5.4 in kcoreaddons generates via cmake KF5CoreAddonsTargets.cmake which contains:

/usr/lib64/cmake/KF5CoreAddons/KF5CoreAddonsTargets.cmake contains:

    44 set_target_properties(KF5::CoreAddons PROPERTIES
    45 INTERFACE_COMPILE_DEFINITIONS "KCOREADDONS_LIB"
    46 INTERFACE_INCLUDE_DIRECTORIES
"${_IMPORT_PREFIX}/include/KF5/KCoreAddons;${_IMPORT_PREFIX}/include/KF5"
    47 INTERFACE_LINK_LIBRARIES "Qt5::Core"
    48 )
    49

Note _IMPORT_PREFIX is being used there. Now according to this code:

http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmExportInstallFileGenerator.cxx;h=89071c052ce28a82f57e06d96b2b7d519259c2f0;hb=HEAD#l72 [^]

_IMPORT_PREFIX is empty if using absolute paths. Thus I'm ending up with invalid "/include/KF5/KcoreAdons" paths.

That's becomes visible when trying to build for example kauth which uses kcoreaddons:

"CMake Error in src/CMakeLists.txt:
  Imported target "KF5::CoreAddons" includes non-existent path

    "/include/KF5/KCoreAddons"

  in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include:

  * The path was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and references files it does not
  provide.

Steps To ReproduceBuild kcoreaddons using such options:
+ CC=x86_64-pld-linux-gcc CXX=x86_64-pld-linux-g++ CPPFLAGS= /usr/bin/cmake '-DCMAKE_VERBOSE_MAKEFILE=ON' '-DCMAKE_BUILD_TYPE=PLD' '-DCMAKE_INSTALL_LIBDIR:PATH=/usr/lib64' '-DCMAKE_INSTALL_PREFIX:PATH=/usr' '-DSYSCONF_INSTALL_DIR:PATH=/etc' '-DCMAKE_CXX_FLAGS_PLD=-O2 -fwrapv -pipe -Wformat -Werror=format-security -gdwarf-4 -fno-debug-types-section -fvar-tracking-assignments -g2 -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fPIC -march=x86-64 -gdwarf-4 -fno-debug-types-section -fvar-tracking-assignments -g2 -DNDEBUG -DQT_NO_DEBUG' '-DCMAKE_C_FLAGS_PLD=-O2 -fwrapv -pipe -Wformat -Werror=format-security -gdwarf-4 -fno-debug-types-section -fvar-tracking-assignments -g2 -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fPIC -march=x86-64 -gdwarf-4 -fno-debug-types-section -fvar-tracking-assignments -g2 -DNDEBUG -DQT_NO_DEBUG' '-DCMAKE_Fortran_FLAGS_PLD=-O2 -fwrapv -pipe -Wformat -Werror=format-security -gdwarf-4 -fno-debug-types-section -fvar-tracking-assignments -g2 -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fPIC -march=x86-64 -gdwarf-4 -fno-debug-types-section -fvar-tracking-assignments -g2 -DNDEBUG -DQT_NO_DEBUG' '-DCMAKE_EXE_LINKER_FLAGS_PLD=-Wl,--as-needed -Wl,--no-copy-dt-needed-entries -Wl,-z,relro -Wl,-z,combreloc ' '-DCMAKE_SHARED_LINKER_FLAGS_PLD=-Wl,--as-needed -Wl,--no-copy-dt-needed-entries -Wl,-z,relro -Wl,-z,combreloc ' '-DCMAKE_MODULE_LINKER_FLAGS_PLD=-Wl,--as-needed -Wl,--no-copy-dt-needed-entries -Wl,-z,relro -Wl,-z,combreloc ' '-DLIB_SUFFIX=64' '-DBUILD_SHARED_LIBS:BOOL=ON' '-DKDE_INSTALL_USE_QT_SYS_PATHS=ON' '-DBIN_INSTALL_DIR=/usr/bin' ../


then build kauth using the same options.

I assume it's unrealistic to expect cmake developers to do such compilations to reproduce. Anyway looking into how cmake generated KF5CoreAddonsTargets.cmake always using _IMPORT_PREFIX and the fact that _IMPORT_PREFIX is empty if using absolute paths should be enough to figure the problem out.
TagsNo tags attached.
Attached Files? file icon KF5CoreAddonsTargets.cmake [^] (3,249 bytes) 2014-11-21 02:33
log file icon kcoreaddons.log [^] (730,386 bytes) 2014-11-21 02:33
log file icon kauth.log [^] (8,604 bytes) 2014-11-21 02:36

 Relationships

  Notes
(0037243)
Arkadiusz Miskiewicz (reporter)
2014-11-21 02:37

 IRC discussion about the problem:

12:05 < arekm> hi, what is "${_IMPORT_PREFIX}" ? I fail to find any docs about it
12:07 <+ngladitz> arekm: where did you see it? the underscore implies that it is internal
12:11 < arekm> ngladitz: in tons of *.cmake files like from KDE for example
12:11 < arekm> /usr/lib64/cmake/KF5CoreAddons/KF5CoreAddonsTargets.cmake: INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include/KF5/KCoreAddons;${_IMPORT_PREFIX}/include/KF5"
12:11 < arekm> /usr/lib64/cmake/KF5CoreAddons/KF5CoreAddonsTargets.cmake: INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include/KF5"
12:11 < arekm> and it seems to be empty thus I'm getting invalid /include/KF5 path
12:12 <+ngladitz> the variable is temporary and should be set in the same file that uses it
12:13 <+ngladitz> right after the generated comment # Compute the installation prefix relative to this file.
12:14 < arekm> no such comment there, http://sprunge.us/HbdP [^]
12:16 <+ngladitz> hm here it would be right after unset(_expectedTargets)
12:17 <+ngladitz> apparently only in the target export file used for installation though
12:17 <+ngladitz> missing in the target export file used for the build
12:17 <+ngladitz> but the build time export file doesn't use _IMPORT_PREFIX either
12:22 <+ngladitz> the sources seem to say it is omitted when the installation destination (of the export file?) is a full path
12:23 <+ngladitz> http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmExportInstallFileGenerator.cxx;h=89071c052ce28a82f57e06d96b2b7d519259c2f0;hb=HEAD#l72 [^]
13:00 < arekm> all that makes it end too early http://sprunge.us/UHdG [^]
13:01 <+ngladitz> I'd try to find out if KF5CoreAddons uses an absolute installation destination for the target exports file
13:03 < arekm> ./CMakeLists.txt:install(EXPORT KF5CoreAddonsTargets DESTINATION "${CMAKECONFIG_INSTALL_DIR}" FILE KF5CoreAddonsTargets.cmake NAMESPACE KF5:: )
13:03 < arekm> ./build/cmake_install.cmake:file(INSTALL DESTINATION "/usr/lib64/cmake/KF5CoreAddons" TYPE FILE FILES "/home/users/arekm/rpm/BUILD/kcoreaddons-5.4.0/build/CMakeFiles/Export/_usr/lib64/cmake/KF5CoreAddons/KF5CoreAddonsTargets.cmake")
13:05 <+ngladitz> ok that sure looks like it does ... so i assume that is why it omits _IMPORT_PREFIX
13:06 < arekm> and there is ./src/lib/CMakeLists.txt:install(TARGETS KF5CoreAddons EXPORT KF5CoreAddonsTargets ${KF5_INSTALL_TARGETS_DEFAULT_ARGS})
13:06 <+ngladitz> the assumption is perhaps that if you install your package configuration file with an absolute path your interfaces can't use relative paths
13:11 < arekm> assumptions are bad ;(
13:14 < arekm> so it looks like I need to somehow force full paths in INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include/KF5" like INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/usr/include/KF5"
13:20 <+ngladitz> hm perhaps also bring it up on the cmake's developer mailinglist ... maybe there should be a hard diagnostic at least (assuming there isn't already in the master branch)
13:25 <+ngladitz> and with an absolute path you'd want INTERFACE_INCLUDE_DIRECTORIES "/usr/include/KF5" (without any reference to _IMPORT_PREFIX)
13:47 < arekm> 3.1rc2 does exactly the same thing :/
13:50 <+ngladitz> were you building KF5CoreAddons? if there is a diagnostic it should be at the time the package configuration file is generated rather than consumed
13:51 < arekm> both, so yes, KF5CoreAddons, too
13:52 < arekm> http://sprunge.us/bGDE [^]
14:01 <+ngladitz> hm yes I see
14:03 <+ngladitz> it does seem to diagnose the issue for targets: http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmExportInstallFileGenerator.cxx;h=89071c052ce28a82f57e06d96b2b7d519259c2f0;hb=HEAD#l501 [^]
14:03 <+ngladitz> so maybe it could/should do for interface properties too
(0037246)
Brad King (manager)
2014-11-21 10:22

 As mentioned in the report the code here:

 http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmExportInstallFileGenerator.cxx;hb=v3.0.2#l72 [^]

sets the ImportPrefix member to use ${_IMPORT_PREFIX} if and only if using a relative install destination. However it looks like cmExportInstallFileGenerator::ReplaceInstallPrefix:

 http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmExportInstallFileGenerator.cxx;hb=v3.0.2#l226 [^]

hard-codes the assumption that ${_IMPORT_PREFIX} will be defined, and uses it as the replacement for the $<INSTALL_PREFIX> generator expression. This may be reasonable because I don't think $<INSTALL_PREFIX> can be a well-defined expression when using an absolute install path. Is this project doing that?
(0037248)
Arkadiusz Miskiewicz (reporter)
2014-11-21 12:11

 Well, _IMPORT_PREFIX is not defined, so don't see how that could be reasonable.

From what I see in sources CMAKE_INSTALL_PREFIX gets defined sometimes.

ftp://ftp.kde.org/pub/kde/stable/frameworks/5.4/kcoreaddons-5.4.0.tar.xz [^]
ftp://ftp.kde.org/pub/kde/stable/frameworks/5.4/kauth-5.4.0.tar.xz [^]
(0037272)
Stephen Kelly (developer)
2014-11-25 08:10

 I guess this has something to do with

 install(TARGETS ... INCLUDES DESTINATION ...)

The method

 cmExportFileGenerator::PopulateIncludeDirectoriesInterface

calls

 cmGeneratorExpression::Preprocess

with the content, which calls

 prefixItems(content, result, "${_IMPORT_PREFIX}/");

I haven't looked any deeper into it yet.
(0037414)
Stephen Kelly (developer)
2014-12-08 13:46

 The problem is that you change some relative paths to absolute paths by setting some variables them on the command line, but you don't set all necessary paths. You need to set the include dir to an absolute path too.

I added a new diagnostic to recognize this in CMake 3.2.

Removing CMAKE_INSTALL_LIBDIR from your command line might also cause the correct files to be generated (why are you setting that?). You might want to discuss some of this stuff on the kde mailing list because apparently those paths and variables are quite a mess.
(0037461)
Brad King (manager)
2014-12-15 11:49

 For reference, the diagnostic mentioned in 0015258:0037414 was proposed here:

 Export: Diagnose issues in INCLUDES DESTINATION while generating
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=29f92485 [^]

 Export: Issue error if generating unusable export file
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2bdb47b2 [^]

However, it was never merged to 'master' because I think we can make the case "just work".
(0037462)
Brad King (manager)
2014-12-15 11:50

 I've added a change that should allow absolute install(EXPORT) destinations even when other pieces are relative:

 install: Allow absolute EXPORT destination with relative targets
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dd089e08 [^]
(0038702)
Robert Maynard (manager)
2015-05-04 09:05

 Closing resolved issues that have not been updated in more than 4 months.

 Issue History
Date Modified Username Field Change
2014-11-21 02:32 Arkadiusz Miskiewicz New Issue
2014-11-21 02:33 Arkadiusz Miskiewicz File Added: KF5CoreAddonsTargets.cmake
2014-11-21 02:33 Arkadiusz Miskiewicz File Added: kcoreaddons.log
2014-11-21 02:36 Arkadiusz Miskiewicz File Added: kauth.log
2014-11-21 02:37 Arkadiusz Miskiewicz Note Added: 0037243
2014-11-21 10:19 Brad King Assigned To => Stephen Kelly
2014-11-21 10:19 Brad King Status new => assigned
2014-11-21 10:22 Brad King Note Added: 0037246
2014-11-21 12:11 Arkadiusz Miskiewicz Note Added: 0037248
2014-11-25 08:10 Stephen Kelly Note Added: 0037272
2014-11-29 09:07 Stephen Kelly Target Version => CMake 3.2
2014-11-29 09:07 Stephen Kelly Description Updated
2014-12-08 13:46 Stephen Kelly Note Added: 0037414
2014-12-08 13:46 Stephen Kelly Status assigned => resolved
2014-12-08 13:46 Stephen Kelly Fixed in Version => CMake 3.2
2014-12-08 13:46 Stephen Kelly Resolution open => fixed
2014-12-15 11:48 Brad King Status resolved => assigned
2014-12-15 11:48 Brad King Resolution fixed => open
2014-12-15 11:48 Brad King Fixed in Version CMake 3.2 =>
2014-12-15 11:49 Brad King Note Added: 0037461
2014-12-15 11:50 Brad King Note Added: 0037462
2014-12-19 08:26 Brad King Assigned To Stephen Kelly => Brad King
2014-12-19 08:26 Brad King Status assigned => resolved
2014-12-19 08:26 Brad King Resolution open => fixed
2014-12-19 08:26 Brad King Fixed in Version => CMake 3.2
2015-05-04 09:05 Robert Maynard Note Added: 0038702
2015-05-04 09:05 Robert Maynard Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team