MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0014317CMakeCMakepublic2013-07-26 04:432015-07-08 08:57
ReporterFabian Saccilotto 
Assigned ToBrad King 
PrioritynormalSeverityfeatureReproducibilityalways
StatusclosedResolutionfixed 
PlatformVisual Studio 2010OSWindowsOS Version8
Product VersionCMake 2.8.11.2 
Target VersionCMake 3.3Fixed in VersionCMake 3.3 
Summary0014317: Configuration dependent install EXPORT
DescriptionCommands
INSTALL(TARGETS ... EXPORT
INSTALL(EXPORT

Installing exported libraries to configuration dependent folder doesn't work at the moment.

Because of the fact that *-targets-<configuration>.cmake files are generated during execution of CMake for the library to export, they contain paths with ${BUILD_TYPE}. During the find_package() stage of the parent project this variable will be empty and therefore an error occurs that the file can't be found.

Extract from *-targets-debug.cmake
set_target_properties(sba PROPERTIES
  IMPORTED_LINK_INTERFACE_LANGUAGES_DEBUG "C"
  IMPORTED_LINK_INTERFACE_LIBRARIES_DEBUG "blas;lapack;f2c"
  IMPORTED_LOCATION_DEBUG "${_IMPORT_PREFIX}/1.6/lib/${BUILD_TYPE}/sba.lib"
  )
Steps To ReproduceInstall a library to a configuration dependent folder and install the export. See the following CMakeLists.txt snippet.


# Snippet from CMakeLists.txt -----------------------------------
add_library(<libname> <sources>)

# Export for later reuse
set(PACKAGE_NAME <packagename>)
set(VERSION <version>)

# Make a directory for each config
install(TARGETS <libname>
  EXPORT ${PACKAGE_NAME}-targets
    RUNTIME DESTINATION ${VERSION}/bin/\${BUILD_TYPE} COMPONENT Runtime
    LIBRARY DESTINATION ${VERSION}/lib/\${BUILD_TYPE} COMPONENT Runtime
    ARCHIVE DESTINATION ${VERSION}/lib/\${BUILD_TYPE} COMPONENT Development}
    )

configure_file(
    ${${PROJECT_NAME}_SOURCE_DIR}/${PACKAGE_NAME}-config.cmake.in
    ${${PROJECT_NAME}_BINARY_DIR}/${PACKAGE_NAME}-config.cmake
  @ONLY
    )

configure_file(
${${PROJECT_NAME}_SOURCE_DIR}/${PACKAGE_NAME}-config-version.cmake.in
${${PROJECT_NAME}_BINARY_DIR}/${PACKAGE_NAME}-config-version.cmake
  @ONLY
    )

install(FILES
  ${${PROJECT_NAME}_BINARY_DIR}/${PACKAGE_NAME}-config.cmake
  ${${PROJECT_NAME}_BINARY_DIR}/${PACKAGE_NAME}-config.cmake
  DESTINATION ${VERSION}
  )

install(EXPORT ${PACKAGE_NAME}-targets DESTINATION ${VERSION})

# *-config.cmake.in ---------------------------------------
# Import the targets
get_filename_component(SELF_DIR "${CMAKE_CURRENT_LIST_FILE}" PATH)
include(${SELF_DIR}/@PACKAGE_NAME@-targets.cmake)
Additional InformationMy proposal to add this feature:
The ${BUILD_TYPE} Variable could be set in the *-targets-<configuration>.cmake file during creation of the files as the configuration is known.

I implemented the code on the source of 2.8.11.2 tag of the git repository and made a patch.

In cmExportFileGenerator::GenerateImportHeaderCode the BUILD_TYPE variable is set if a configuration is available. This allows users to use that variable in install paths.

//----------------------------------------------------------------------------
void cmExportFileGenerator::GenerateImportHeaderCode(std::ostream& os,
                                                     const char* config)
{
  os << "#----------------------------------------------------------------\n"
     << "# Generated CMake target import file";
  if(config)
    {
    os << " for configuration \"" << config << "\".\n";
    }
  else
    {
    os << ".\n";
    }
  os << "#----------------------------------------------------------------\n"
     << "\n";
  this->GenerateImportConfigurationCode(os, config);
  this->GenerateImportVersionCode(os);
}

//----------------------------------------------------------------------------
void cmExportFileGenerator::GenerateImportConfigurationCode(std::ostream& os,
                                                     const char* config)
{
  // Store the used configuration, this will allow configuration dependent
  // paths in multi-configuration environments
  if(config)
    {
    os << "# Set configuration for use in paths.\n"
       << "set(BUILD_TYPE " << config << ")\n"
       << "\n";
    }
}
TagsNo tags attached.
Relationships
Attached Filespatch config_dependent_install.patch (2,365) 2013-07-26 04:43
https://public.kitware.com/Bug/file/4827/config_dependent_install.patch
patch generator_expressions.patch (4,331) 2013-11-28 08:59
https://public.kitware.com/Bug/file/4985/generator_expressions.patch
Issue History
Date ModifiedUsernameFieldChange
2013-07-26 04:43Fabian SaccilottoNew Issue
2013-07-26 04:43Fabian SaccilottoFile Added: config_dependent_install.patch
2013-07-29 11:06Brad KingNote Added: 0033625
2013-07-29 11:06Brad KingStatusnew => backlog
2013-07-29 11:08Brad KingNote Added: 0033626
2013-11-28 08:59Dominik BernhardtFile Added: generator_expressions.patch
2013-11-28 09:01Dominik BernhardtNote Added: 0034610
2013-12-02 09:06Brad KingAssigned To => Stephen Kelly
2013-12-02 09:06Brad KingStatusbacklog => assigned
2013-12-02 09:06Brad KingNote Added: 0034663
2013-12-02 11:07Stephen KellyNote Added: 0034677
2013-12-04 12:21Stephen KellyStatusassigned => backlog
2013-12-04 12:21Stephen KellyAssigned ToStephen Kelly =>
2015-02-12 12:57Brad KingNote Added: 0037959
2015-02-12 12:58Brad KingAssigned To => Brad King
2015-02-12 12:58Brad KingStatusbacklog => resolved
2015-02-12 12:58Brad KingResolutionopen => fixed
2015-02-12 12:58Brad KingFixed in Version => CMake 3.3
2015-02-12 12:58Brad KingTarget Version => CMake 3.3
2015-07-08 08:57Robert MaynardNote Added: 0039049
2015-07-08 08:57Robert MaynardStatusresolved => closed

Notes
(0033625)
Brad King   
2013-07-29 11:06   
You can achieve this indirectly with existing CMake by using the install(TARGETS)'s CONFIGURATIONS option to specify separate rules for each configuration. Of course it would be much cleaner to have direct support for per-configuration destinations without having to know the list of possible configurations.

The BUILD_TYPE variable in cmake_install.cmake files is an undocumented implementation detail not meant for use in the way you propose.

Instead we should consider supporting generator expressions in the install destination e.g.

 DESTINATION ${VERSION}/bin/$<CONFIGURATION>
(0033626)
Brad King   
2013-07-29 11:08   
Corresponding discussion started on cmake-developers mailing list:

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7554 [^]
(0034610)
Dominik Bernhardt   
2013-11-28 09:01   
I patched the current nightly branch to support generator expressions for the destinations. Although it might not be the most elegant implementation it at least severs my purposes.

See attached patch:generator_expressions.patch
(0034663)
Brad King   
2013-12-02 09:06   
Steve, please take a look at the proposed patch.
(0034677)
Stephen Kelly   
2013-12-02 11:07   
The patch is not ready for master as it is. It needs to handle the string starting with a genex and what that means for whether it is a relative path etc.

It is also missing a change to the ExportImport unit test to use a genex in the appropriate places. Adding some $<1:...> or $<0:...> would be enough.

It looks like changing cmInstallGenerator::GetInstallDestination to take a cmTarget* and a const char *config could be the way forward, but that probably requires more changes to make all destinations genex-capable, which might be wanted.
(0037959)
Brad King   
2015-02-12 12:57   
The following commits implement this feature for install(TARGETS) and add test cases:

 cmInstallGenerator: Move GetDestination to subclasses that need it
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f99991db [^]

 cmInstallGenerator: Refactor computation of absolute install dest
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=290ca8e2 [^]

 cmInstallGenerator: Fix check for absolute install destinations
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ebd556ca [^]

 cmInstallGenerator: Pass destination explicitly to AddInstallRule
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7607c3d1 [^]

 install: Allow generator expressions in TARGETS DESTINATION
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f30022eb [^]
(0039049)
Robert Maynard   
2015-07-08 08:57   
Closing resolved issues that have not been updated in more than 4 months.