MantisBT - CMake
View Issue Details
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.
Additional Information
TagsNo tags attached.
Relationships
Attached Files? KF5CoreAddonsTargets.cmake (3,249) 2014-11-21 02:33
https://public.kitware.com/Bug/file/5303/KF5CoreAddonsTargets.cmake
log kcoreaddons.log (730,386) 2014-11-21 02:33
https://public.kitware.com/Bug/file/5304/kcoreaddons.log
log kauth.log (8,604) 2014-11-21 02:36
https://public.kitware.com/Bug/file/5305/kauth.log
Issue History
Date ModifiedUsernameFieldChange
2014-11-21 02:32Arkadiusz MiskiewiczNew Issue
2014-11-21 02:33Arkadiusz MiskiewiczFile Added: KF5CoreAddonsTargets.cmake
2014-11-21 02:33Arkadiusz MiskiewiczFile Added: kcoreaddons.log
2014-11-21 02:36Arkadiusz MiskiewiczFile Added: kauth.log
2014-11-21 02:37Arkadiusz MiskiewiczNote Added: 0037243
2014-11-21 10:19Brad KingAssigned To => Stephen Kelly
2014-11-21 10:19Brad KingStatusnew => assigned
2014-11-21 10:22Brad KingNote Added: 0037246
2014-11-21 12:11Arkadiusz MiskiewiczNote Added: 0037248
2014-11-25 08:10Stephen KellyNote Added: 0037272
2014-11-29 09:07Stephen KellyTarget Version => CMake 3.2
2014-11-29 09:07Stephen KellyDescription Updatedbug_revision_view_page.php?rev_id=1628#r1628
2014-12-08 13:46Stephen KellyNote Added: 0037414
2014-12-08 13:46Stephen KellyStatusassigned => resolved
2014-12-08 13:46Stephen KellyFixed in Version => CMake 3.2
2014-12-08 13:46Stephen KellyResolutionopen => fixed
2014-12-15 11:48Brad KingStatusresolved => assigned
2014-12-15 11:48Brad KingResolutionfixed => open
2014-12-15 11:48Brad KingFixed in VersionCMake 3.2 =>
2014-12-15 11:49Brad KingNote Added: 0037461
2014-12-15 11:50Brad KingNote Added: 0037462
2014-12-19 08:26Brad KingAssigned ToStephen Kelly => Brad King
2014-12-19 08:26Brad KingStatusassigned => resolved
2014-12-19 08:26Brad KingResolutionopen => fixed
2014-12-19 08:26Brad KingFixed in Version => CMake 3.2
2015-05-04 09:05Robert MaynardNote Added: 0038702
2015-05-04 09:05Robert MaynardStatusresolved => closed

Notes
(0037243)
Arkadiusz Miskiewicz   
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   
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   
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   
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   
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   
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   
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   
2015-05-04 09:05   
Closing resolved issues that have not been updated in more than 4 months.