Re: [cmake-developers] [CMake 0014317]: Configuration dependent install EXPORT
On 02/11/2015 04:19 AM, opensgu...@web.de wrote: Is there any chance the feature to support genex in DESTINATION the install() command will be added? I've implemented it for install(TARGETS): http://www.cmake.org/Bug/view.php?id=14317#c37959 That is the important one AFAICT. For other install() commands more work would be needed because they do not all already have per-config actions. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0014317]: Configuration dependent install EXPORT
Brad King brad.king at ... writes: Steve, On 07/26/2013 04:43 AM, Mantis Bug Tracker wrote: http://www.cmake.org/Bug/view.php?id=14317 What do you think about adding generator expressions to install DESTINATION options. In particular the CONFIGURATION genex would be useful in this case. Thanks, -Brad Generator expressions given to DESTINATION in the install() command unfortunately are still not supported as of 3.1.2, e.g. install( TARGETS mylib EXPORT mylib ARCHIVE DESTINATION lib/CONFIG ) Without this, I cant find any satisfiable solution installing archive and runtime files for multi-configuration projects (VS) using the export mechanism. Visual Studio users really suffer from this, as only one configuration can be used. Is there any chance the feature to support genex in DESTINATION the install() command will be added? The ticket 0014317 (http://www.cmake.org/Bug/view.php?id=14317) is still open. Same unsolved problem: http://public.kitware.com/pipermail/cmake/2013-July/055359.html. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0014317]: Configuration dependent install EXPORT
Brad King brad.king@... writes: Steve, On 07/26/2013 04:43 AM, Mantis Bug Tracker wrote: http://www.cmake.org/Bug/view.php?id=14317 What do you think about adding generator expressions to install DESTINATION options. In particular the $CONFIGURATION genex would be useful in this case. Thanks, -Brad Generator expressions given to DESTINATION in the install() command unfortunately are still not supported as of 3.1.1, e.g. install( TARGETS mylib EXPORT mylib ARCHIVE DESTINATION lib/$CONFIG ) Without this, I can't find any satisfiable solution installing archive and runtime files for multi-configuration projects (VS) using the export mechanism. Visual Studio users really suffer from this, as only one configuration can be used. Is there any chance this feature (genex) will be added? The ticket 0014317 (http://www.cmake.org/Bug/view.php?id=14317) is still open. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0014317]: Configuration dependent install EXPORT
Brad King wrote: On 07/30/2013 09:46 AM, Stephen Kelly wrote: That is, parameters to install(TARGETS) are evaluated at export time, and otherwise the contents of the property are reproduced verbatim. Yes, I think this makes sense. The install rules run as part of the current project's build just like custom commands, so it makes sense to evaluate generator expressions immediately. However, the implementation may be a bit complicated because now cmake_install.cmake script code will have to branch on BUILD_TYPE to pick which install rule to run. There is already infrastructure for this to support the CONFIGURATIONS option of install(TARGETS) so maybe it is okay. I think two things are being confused here. One is the DESTINATION for things that are installed by the current command. Eg: install(TARGETS foo RUNTIME DESTINATION bin LIBRARY DESTINATION lib ARCHIVE DESTINATION lib ) install(FILES foo.h DESTINATION include ) The bug report is about adding genex support to those destinations. The new feature is install(TARGETS foo INCLUDES DESTINATION include ) which does not result in installing anything to 'include/', but only populates a property. This is quite separate to what you describe above. I propose that we deal with what you describe above after 2.8.12. For supporting generator expressions in install(TARGETS foo INCLUDES DESTINATION include ) I've pushed a INCLUDES-DESTINATION-partial-eval topic to my clone with some ideas for it. Please let me know what you think. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0014317]: Configuration dependent install EXPORT
On 07/31/2013 07:53 AM, Stephen Kelly wrote: I think two things are being confused here. One is the DESTINATION for things that are installed by the current command. Eg: install(TARGETS foo RUNTIME DESTINATION bin LIBRARY DESTINATION lib ARCHIVE DESTINATION lib ) install(FILES foo.h DESTINATION include ) The bug report is about adding genex support to those destinations. Yes, it's also the one that started this thread. Do we agree that full generate-time evaluation is appropriate for these? If so then the implementation will require BUILD_TYPE conditional blocks in generated cmake_install.cmake files. I propose that we deal with what you describe above after 2.8.12. Yes, definately. For supporting generator expressions in install(TARGETS foo INCLUDES DESTINATION include ) I've pushed a INCLUDES-DESTINATION-partial-eval topic to my clone with some ideas for it. Please let me know what you think. Are you proposing this for inclusion in 2.8.12? IMO it can wait along with the rest. I forgot, which config-related generator expressions on imported targets honor MAP_IMPORTED_CONFIG_CONFIG? What is the behavior when a not-allowed expression like STREQUAL is used? Does it produce an error message? -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0014317]: Configuration dependent install EXPORT
Brad King wrote:
I've pushed a INCLUDES-DESTINATION-partial-eval topic to my clone with
some ideas for it. Please let me know what you think.
Are you proposing this for inclusion in 2.8.12?
Yes.
IMO it can wait along with the rest.
As INCLUDES DESTINATION is already in master, that would be a behavior
change, and probably need a policy. Currently if you use
install(TARGETS foo EXPORT fooTargets
INCLUDES DESTINATION $INSTALL_PREFIX/include/$STREQUAL:foo,bar
)
the result in fooTargets.cmake is
INTERFACE_INCLUDE_DIRECTORIES
${_IMPORT_PREFIX}/include/$STREQUAL:foo,bar
if the genex is evaluated at export time in a follow-up release, the result
would instead be
INTERFACE_INCLUDE_DIRECTORIES
${_IMPORT_PREFIX}/include/0
So, I think for the case of INCLUDES DESTINATION, we can either decide and
fix it now, or revert the change adding it for 2.8.12.
I forgot, which config-related generator expressions on imported
targets honor MAP_IMPORTED_CONFIG_CONFIG?
The $CONFIG:cfg expression should always process those, if used on any of
the target properties used for the interface.
What is the behavior when a not-allowed expression like
STREQUAL is used? Does it produce an error message?
In master the STREQUAL is reproduced verbatim. In my topic it is evaluated
at export time.
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0014317]: Configuration dependent install EXPORT
Brad King wrote: The bug report is about adding genex support to those destinations. Yes, it's also the one that started this thread. Do we agree that full generate-time evaluation is appropriate for these? If so then the implementation will require BUILD_TYPE conditional blocks in generated cmake_install.cmake files. I don't know yet. I haven't looked into the generated cmake_install.cmake files. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0014317]: Configuration dependent install EXPORT
On 07/31/2013 09:25 AM, Stephen Kelly wrote: As INCLUDES DESTINATION is already in master, that would be a behavior change, and probably need a policy. Technically that will be true for the real DESTINATION values too but I doubt anyone has installed to a path with $ in it. Since INCLUDES DESTINATION populates a property that supports generator expressions they are likely to be used. I see your point. So, I think for the case of INCLUDES DESTINATION, we can either decide and fix it now, or revert the change adding it for 2.8.12. Let's try to decide now and revert as a last resort. So the only reason we need partial evaluation is to leave configuration-dependent sub-expressions untouched since the configuration is not known until generation of the consumer? I think the partial evaluation should work by traversing the expression tree and collapsing sub-tree that does not depend on the configuration into a leaf node with a constant value. Alternatively we could generate an error if any config-dependent expressions are found in INCLUDES DESTINATION and otherwise do full evaluation. That way we can decide on the partial evaluation semantics later. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0014317]: Configuration dependent install EXPORT
Brad King wrote:
So, I think for the case of INCLUDES DESTINATION, we can either decide
and fix it now, or revert the change adding it for 2.8.12.
Let's try to decide now and revert as a last resort.
So the only reason we need partial evaluation is to leave
configuration-dependent sub-expressions untouched since the
configuration is not known until generation of the consumer?
Yes, I think that is the case.
Includes are not generally different files for debug/release as the
preprocessor is generally used instead where needed. However, let's assume
that for the debug config we install a foo_debug.h, and otherwise not.
To get more concrete, here's some cases I could think of:
A) I want to install all includes to
set(config_suffix $$CONFIG:Debug:debug$NOT:$CONFIG:Debug:release)
INCLUDES DESTINATION $INSTALL_PREFIX/include/${config_suffix}
and for consumers of the target to get either the 'debug' or the 'release'
include directory.
I would use
install(FILES ${files}
DESTINATION include/${config_suffix})
(when that works) to install the files.
B) I only want to install the foo_debug.h to a special location
install(FILES ${files}
DESTINATION include)
install(FILES foo_debug.h
DESTINATION include/debug
CONFIGURATIONS Debug
)
INCLUDES DESTINATION
include;$$CONFIG:Debug:$INSTALL_PREFIX/include/debug
So that consumers get both include directories. This probably works already
with master.
C) As B, but with target-named include paths
install(FILES ${foo_files}
DESTINATION include/foo)
install(FILES ${bar_files}
DESTINATION include/bar)
install(FILES foo_debug.h
DESTINATION include/foo/debug
CONFIGURATIONS Debug
)
set(basic_path $INSTALL_PREFIX/include/$TARGET_PROPERTY:NAME)
INCLUDES DESTINATION
${basic_path}
$$CONFIG:Debug:${basic_path}/debug
This does not work with master. However, there is a workaround.
target_include_directories(foo INTERFACE
include/foo
$$CONFIG:Debug:$INSTALL_PREFIX/include/foo/debug
)
ie, not using the INCLUDES DESTINATION feature, which is 'just' a
convenience for the 'common case'.
I think the partial evaluation should work by traversing
the expression tree and collapsing sub-tree that does not
depend on the configuration into a leaf node with a constant
value.
Alternatively we could generate an error if any config-dependent
expressions are found in INCLUDES DESTINATION and otherwise
do full evaluation. That way we can decide on the partial
evaluation semantics later.
Yes, such an error would be quite easy to generate, as that fact is already
recorded. I considered that and decided not to implement it because the bug
report specifically wanted config support. However, that was for libraries,
not includes. Config sensitive dirs are likely more common for libraries
than includes, so actually I think it would be fine to make that an error
and always do full evaluation.
I've pushed INCLUDES-DESTINATION-no-config to my clone with an
implementation. Can I merge it to next?
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0014317]: Configuration dependent install EXPORT
On 07/31/2013 11:05 AM, Stephen Kelly wrote:
Config sensitive dirs are likely more common for libraries
than includes, so actually I think it would be fine to make that an error
and always do full evaluation.
To clarify, the no-config rule is for INCLUDES DESTINATION only, but full
with-config evaluation will be allowed for a real DESTINATION. The
config can be honored for file destinations. For targets we generate
a per-config IMPORTED_LOCATION_CONFIG anyway. We will wait for after
2.8.12 for the file destination generator expressions.
I've pushed INCLUDES-DESTINATION-no-config to my clone with an
implementation. Can I merge it to next?
Yes, but one comment first:
+ if (cge-GetHadContextSensitiveCondition())
+{
+cmMakefile* mf = target-GetMakefile();
+cmOStringStream e;
+e Target \ target-GetName() \ is installed with
+INCLUDES DESTINATION set to a configuration sensitive path. This is
Does context sensitive condition ever mean something other than
configuration sensitive? If so then users may produce a case that
triggers this error in a confusing manner.
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0014317]: Configuration dependent install EXPORT
Brad King wrote:
On 07/31/2013 11:05 AM, Stephen Kelly wrote:
Config sensitive dirs are likely more common for libraries
than includes, so actually I think it would be fine to make that an error
and always do full evaluation.
To clarify, the no-config rule is for INCLUDES DESTINATION only, but full
with-config evaluation will be allowed for a real DESTINATION. The
config can be honored for file destinations. For targets we generate
a per-config IMPORTED_LOCATION_CONFIG anyway. We will wait for after
2.8.12 for the file destination generator expressions.
Right.
I've pushed INCLUDES-DESTINATION-no-config to my clone with an
implementation. Can I merge it to next?
Yes, but one comment first:
+ if (cge-GetHadContextSensitiveCondition())
+{
+cmMakefile* mf = target-GetMakefile();
+cmOStringStream e;
+e Target \ target-GetName() \ is installed with
+INCLUDES DESTINATION set to a configuration sensitive path. This is
Does context sensitive condition ever mean something other than
configuration sensitive? If so then users may produce a case that
triggers this error in a confusing manner.
Yes, is also means that TARGET_POLICY was used, or a
LINK_INTERFACE_DEPENDENT_{BOOL,STRING} property was used in the generator
expression.
In the case of the target policy, it makes sense to error on this because
there is no point in changing the property based on the policy setting of
the consumer of the IMPORTED target.
For LINK_INTERFACE_DEPENDENT_STRING properties it is a bit unfortunate,
because we can't use the QT_MAJOR_VERSION target property and install to
either include/Qt4Based or include/Qt5Based depending on which version we're
installing for.
However, that is still easily possible with target_include_directories.
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0014317]: Configuration dependent install EXPORT
On 07/29/2013 06:57 PM, Stephen Kelly wrote: Yes, $CONFIGURATION should work both before and after export. So the question is how to know whether to evaluate it during export or write it literally in the file. In this case we want to expand it during export because we want $CONFIGURATION to refer to the build configuration being installed. INCLUDES DESTINATION include/$TARGET_PROPERTY:NAME [snip] The problem (apart from NAME not being currently a target property) is that the $TARGET_PROPERTY:NAME is reproduced verbatim in theTargetsExport.cmake. There the target names are TP1::foo etc, and include/TP1::foo does not exist. Again the problem is when evaluation occurs. The $INSTALL_PREFIX works in the INCLUDES DESTINATION because it is replaced by preprocessing during export. Does anything else get replaced by preprocessing? For $CONFIGURATION it should be fine, but probably also involves replacing (IMPORTED_)?LOCATION(_CONFIG)? with a genex-capable LOCATION. The history of the LOCATION property is complicated enough already. If we do add genex support we should create a new name to distinguish it. However, why would allowing $CONFIGURATION in the destination require a genex location? We generate an install rule for a given configuration with $CONFIGURATION replaced and then put the corresponding result in IMPORTED_LOCATION_CONFIG. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0014317]: Configuration dependent install EXPORT
Brad King wrote: On 07/29/2013 06:57 PM, Stephen Kelly wrote: Yes, $CONFIGURATION should work both before and after export. So the question is how to know whether to evaluate it during export or write it literally in the file. In this case we want to expand it during export because we want $CONFIGURATION to refer to the build configuration being installed. Right. I had thought that $CONFIGURATION would be evaluated by the reader of the IMPORTED_LOCATION property on the IMPORTED target. I think you are right that it makes more sense to replace it at generate- time. The $INSTALL_PREFIX works in the INCLUDES DESTINATION because it is replaced by preprocessing during export. Does anything else get replaced by preprocessing? Target names get replaced by namespaced target names, and the INSTALL_INTERFACE or BUILD_INTERFACE gets stripped. For $CONFIGURATION it should be fine, but probably also involves replacing (IMPORTED_)?LOCATION(_CONFIG)? with a genex-capable LOCATION. The history of the LOCATION property is complicated enough already. If we do add genex support we should create a new name to distinguish it. However, why would allowing $CONFIGURATION in the destination require a genex location? We generate an install rule for a given configuration with $CONFIGURATION replaced and then put the corresponding result in IMPORTED_LOCATION_CONFIG. Yes, that makes more sense. So, the remaining question is when to evaluate the generator expressions. I agree that evaluating them at export time is a better idea. That means that I should patch the INCLUDES DESTINATION feature to do a complete evaluation, not just a preprocessing. I think that makes sense for all DESTINATION components. So, install(TARGETS foo INCLUDES DESTINATION include/$TARGET_PROPERTY:NAME) will result in include/foo in the INTERFACE_INCLUDE_DIRECTORIES of the IMPORTED target. However, set_property(TARGET foo APPEND PROPERTY INTERFACE_INCLUDE_DIRECTORIES include/$TARGET_PROPERTY:NAME ) will result in include/$TARGET_PROPERTY:NAME in the INTERFACE_INCLUDE_DIRECTORIES of the IMPORTED target. That is, parameters to install(TARGETS) are evaluated at export time, and otherwise the contents of the property are reproduced verbatim. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0014317]: Configuration dependent install EXPORT
On 07/30/2013 09:46 AM, Stephen Kelly wrote: That is, parameters to install(TARGETS) are evaluated at export time, and otherwise the contents of the property are reproduced verbatim. Yes, I think this makes sense. The install rules run as part of the current project's build just like custom commands, so it makes sense to evaluate generator expressions immediately. However, the implementation may be a bit complicated because now cmake_install.cmake script code will have to branch on BUILD_TYPE to pick which install rule to run. There is already infrastructure for this to support the CONFIGURATIONS option of install(TARGETS) so maybe it is okay. Thanks, -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0014317]: Configuration dependent install EXPORT
Brad King wrote: Steve, On 07/26/2013 04:43 AM, Mantis Bug Tracker wrote: http://www.cmake.org/Bug/view.php?id=14317 What do you think about adding generator expressions to install DESTINATION options. In particular the $CONFIGURATION genex would be useful in this case. Yes, $CONFIGURATION should work both before and after export. One of my goals with the INCLUDES DESTINATION feature which can not currently be realized is this: install(TARGETS foo bar bat EXPORT theTargets ... INCLUDES DESTINATION include/$TARGET_PROPERTY:NAME ) install(EXPORT theTargets NAMESPACE TP1:: ) install(FILES foo.h DESTINATION include/foo) install(FILES bar.h DESTINATION include/bar) install(FILES bat.h DESTINATION include/bat) The problem (apart from NAME not being currently a target property) is that the $TARGET_PROPERTY:NAME is reproduced verbatim in theTargetsExport.cmake. There the target names are TP1::foo etc, and include/TP1::foo does not exist. The $INSTALL_PREFIX works in the INCLUDES DESTINATION because it is replaced by preprocessing during export. A new $TARGET_NAME_PP could be introduced to make the above possible by being replaced during preprocessing too, or a target property could be populated like TARGET_BUILD_NAME. I didn't like the idea of leaking build- details to export files, and the TARGET_NAME_PP is not super elegant either, so I left the above as out of scope for now. However, similar issues could arise by adding genexes to any DESTINATION component of install, if a generator expression reads a property from a target, and that property is not exported. That's probably something that can be just documented though. For $CONFIGURATION it should be fine, but probably also involves replacing (IMPORTED_)?LOCATION(_CONFIG)? with a genex-capable LOCATION. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014317]: Configuration dependent install EXPORT
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=14317
==
Reported By:Fabian Saccilotto
Assigned To:
==
Project:CMake
Issue ID: 14317
Category: CMake
Reproducibility:always
Severity: feature
Priority: normal
Status: new
==
Date Submitted: 2013-07-26 04:43 EDT
Last Modified: 2013-07-26 04:43 EDT
==
Summary:Configuration dependent install EXPORT
Description:
Commands
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 Reproduce:
Install 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 Information:
My 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;
}
}
==
Issue History
Date ModifiedUsername FieldChange
==
2013-07-26 04:43 Fabian SaccilottoNew Issue
2013-07-26 04:43 Fabian SaccilottoFile Added:
