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 ...> 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 $ 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/$" ) 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 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 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 $ 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/$" ) 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/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_ 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/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_ 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:
>> 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 $<$:debug>$:release>)
INCLUDES DESTINATION "$/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;$<$:$/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 $/include/<$)
INCLUDES DESTINATION
"${basic_path}"
"$<$:${basic_path}/debug>"
This does not work with master. However, there is a workaround.
target_include_directories(foo INTERFACE
include/foo
"$<$:$/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 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: >> 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
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 $/include/$
)
the result in fooTargets.cmake is
INTERFACE_INCLUDE_DIRECTORIES
"${_IMPORT_PREFIX}/include/$"
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_?
The $ 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
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_? 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: > 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/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: > On 07/29/2013 06:57 PM, Stephen Kelly wrote: >> Yes, $ 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 $ to > refer to the build configuration being installed. Right. I had thought that $ 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 $ 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 $ it should be fine, but probably also involves >> replacing (IMPORTED_)?LOCATION(_)? 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 $ in the destination > require a genex location? We generate an install rule for a > given configuration with $ replaced and then > put the corresponding result in IMPORTED_LOCATION_. 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/$) 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/$ ) will result in "include/$" 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/29/2013 06:57 PM, Stephen Kelly wrote: > Yes, $ 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 $ to refer to the build configuration being installed. >INCLUDES DESTINATION include/$ [snip] > The problem (apart from NAME not being currently a target property) is that > the $ 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 $ works in the INCLUDES DESTINATION because it is > replaced by preprocessing during export. Does anything else get replaced by preprocessing? > For $ it should be fine, but probably also involves replacing > (IMPORTED_)?LOCATION(_)? 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 $ in the destination require a genex location? We generate an install rule for a given configuration with $ replaced and then put the corresponding result in IMPORTED_LOCATION_. -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 $ genex > would be useful in this case. Yes, $ 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/$ ) 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 $ is reproduced verbatim in theTargetsExport.cmake. There the target names are TP1::foo etc, and include/TP1::foo does not exist. The $ works in the INCLUDES DESTINATION because it is replaced by preprocessing during export. A new $ 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 $ it should be fine, but probably also involves replacing (IMPORTED_)?LOCATION(_)? 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
Re: [cmake-developers] [CMake 0014317]: Configuration dependent install EXPORT
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 $ genex would be useful in this case. 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
[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-.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( )
# Export for later reuse
set(PACKAGE_NAME )
set(VERSION )
# Make a directory for each config
install(TARGETS
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-.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: config_dependent_install.patch
