Re: [cmake-developers] FindBacktrace.cmake
2013/7/29 Alexander Neundorf neund...@kde.org: Hi Vadim, On Sunday 28 July 2013, you wrote: 2013/7/23 Alexander Neundorf neund...@kde.org: On Tuesday 09 July 2013, Brad King wrote: On 07/08/2013 05:51 PM, Vadim Zhukov wrote: I'm not sure whether resetting CMAKE_REQUIRED_* is the desired behavior. The example in the CMakePushCheckState.cmake documentation tells the opposite, and I think that appending values have a point by adding some sort of a flexibility for writers of other CMake project files and other CMake modules. Also, I see the same logic (append instead of rewrite) is used in other CMake modules (in KDE at least, where CMakePushCheckState.cmake did came from). And if CMAKE_REQUIRED_* should be generally reset within module, then I propose adding a third macro in CMakePushCheckState.cmake, say, cmake_reset_check_state(), which will do this. I'm adding Alexander Neundorf to the thread to make things more clear, as he developed CMakePushCheckState.cmake module. Alexander, could you, please, explain the way CMakePushCheckState macros should be used? I would like Alex's opinion on this, but we must either use CMAKE_REQUIRED_* to report the results (as you did originally) or not use the caller's CMAKE_REQUIRED_* to perform the test. Otherwise the results will not be consistent. We have never (intentionally) defined CMAKE_REQUIRED_* as the input to a _find_ module before, only to _check_ macros. The check state stack module helps a project handle its own check accumulation Yes, that was the intention. Adding a cmake_reset_check_state() sounds good. and AFAIK is not meant as an API between a project and CMake find modules. It looks like a few find modules already use check macros and do not pay any attention to whether CMAKE_REQUIRED_* is defined. These may also need to be cleaned up based on the results of this discussion. I found it only in FindGIF.cmake right now. There the reset() could be used then. Brad and Alexander, With all input from you and after setting up local development repo, I created and pushed two branches to stage: 1. add-cmake_reset_check_state, adding CMAKE_RESET_CHECK_STATE() macro and optional resetting functionality in CMAKE_PUSH_CHECK_STATE(): http://cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/add-cmake _reset_check_state Looks good, but two comments: The documentation does not mention the new optional RESET argument of cmake_push_check_state(). It looks like there is something missing. These macros can be used to save, restore and reset the state maybe to make clear that reset here means setting empty: These macros can be used to save, restore and reset (i.e. clear) the state Thank you, Alexander. I've fixed both points you've mentioned and merged the add-cmake_reset_check_state branch into the next. -- WBR, Vadim Zhukov -- 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] FindBacktrace.cmake
2013/7/28 Rolf Eike Beer e...@sf-mail.de: On Sun Jul 28 15:46:27 2013 Vadim Zhukov persg...@gmail.com wrote: With all input from you and after setting up local development repo, I created and pushed two branches to stage: If I understand correctly, there should be zero fallout in the night build, and after that, given there will be no blockers, I should merge them into the next branch, right? If you don't merge them to next they will get no coverage as next is what the nightlies build. Oh. Thank you, I've messed up the info from Wiki in my mind. -- WBR, Vadim Zhukov -- 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 is slow for project with hundred target and one command with large number of dependencies
Nicolas Desprès wrote:
It was fastest because it was not doing the right thing. I tried to patch
it properly and the benchmark are the same whether we use the default
comparison functor or mine.
So I think you can merge it like that. I have pushed a new version without
the comment.
I still haven't tried it, but there are still style issues.
* Don't put an else after a return
* Wrap single line blocks in {}
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 is slow for project with hundred target and one command with large number of dependencies
On Mon, Jul 29, 2013 at 12:57 PM, Stephen Kelly steve...@gmail.com wrote:
Nicolas Desprès wrote:
It was fastest because it was not doing the right thing. I tried to patch
it properly and the benchmark are the same whether we use the default
comparison functor or mine.
So I think you can merge it like that. I have pushed a new version
without
the comment.
I still haven't tried it, but there are still style issues.
* Don't put an else after a return
* Wrap single line blocks in {}
Fixed and force-pushed. Sorry for the inconvenience. I am not used to this
style yet.
Thanks for the review.
-Nico
--
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 is slow for project with hundred target and one command with large number of dependencies
Nicolas Desprès wrote:
On Mon, Jul 29, 2013 at 12:57 PM, Stephen Kelly
steve...@gmail.com wrote:
Nicolas Desprès wrote:
It was fastest because it was not doing the right thing. I tried to
patch it properly and the benchmark are the same whether we use the
default comparison functor or mine.
So I think you can merge it like that. I have pushed a new version
without
the comment.
I still haven't tried it, but there are still style issues.
* Don't put an else after a return
* Wrap single line blocks in {}
Fixed and force-pushed. Sorry for the inconvenience. I am not used to this
style yet.
Your Compare::operator() contains this:
if (j == s2.rend())
{
return false;
}
return false;
Any reason not to simplify that?
Also, I don't see why the custom comparison functor is needed at all. I
removed it and sped up the test significantly. Can you explain?
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 is slow for project with hundred target and one command with large number of dependencies
On Mon, Jul 29, 2013 at 2:09 PM, Stephen Kelly steve...@gmail.com wrote:
Nicolas Desprès wrote:
On Mon, Jul 29, 2013 at 12:57 PM, Stephen Kelly
steve...@gmail.com wrote:
Nicolas Desprès wrote:
It was fastest because it was not doing the right thing. I tried to
patch it properly and the benchmark are the same whether we use the
default comparison functor or mine.
So I think you can merge it like that. I have pushed a new version
without
the comment.
I still haven't tried it, but there are still style issues.
* Don't put an else after a return
* Wrap single line blocks in {}
Fixed and force-pushed. Sorry for the inconvenience. I am not used to
this
style yet.
Your Compare::operator() contains this:
if (j == s2.rend())
{
return false;
}
return false;
Any reason not to simplify that?
Because I used to have a comment in the else branch of the if, that I
removed because part of it was wrong
https://github.com/nicolasdespres/CMake/commit/59c871da8b00554812e93ba9c6e47d864424efb0#L0R2023(the
part about the optimization). Then I kept the code without thinking
more about it.
Also, I don't see why the custom comparison functor is needed at all. I
removed it and sped up the test significantly. Can you explain?
I had some failing tests because the previous algorithm was not a plain
strcpy().
I have restored the comment. I prefer to keep the too branch even if both
return false to make it clear that the comment apply only in this case and
that it is the only difference with a normal strcpy(3) algorithm.
Cheers,
--
Nicolas Desprès
--
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 is slow for project with hundred target and one command with large number of dependencies
Nicolas Desprès wrote: Also, I don't see why the custom comparison functor is needed at all. I removed it and sped up the test significantly. Can you explain? I had some failing tests because the previous algorithm was not a plain strcpy(). I don't see any strcpy(). Anyway, I think that's as much useful review I can do for you. I think Brad will have to do the rest. 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 is slow for project with hundred target and one command with large number of dependencies
On Mon, Jul 29, 2013 at 2:25 PM, Stephen Kelly steve...@gmail.com wrote: Nicolas Desprès wrote: Also, I don't see why the custom comparison functor is needed at all. I removed it and sped up the test significantly. Can you explain? I had some failing tests because the previous algorithm was not a plain strcpy(). I don't see any strcpy(). Anyway, I think that's as much useful review I can do for you. I think Brad will have to do the rest. Arg. Sorry for being unclear (English is not my mother tongue). The std::lessstring comparator do the same thing (as strcpy() 0). Unfortunately, we cannot use it here because the previous (O(N)) implementation of cmMakefile::GetSourceFileWithOutput(const char*) was more complex than that (have a look to the code my path replaces). Of course, I first tried with the default comparator to save me some work but some tests were failing. Namely: ExportImport and CustomCommand. Hope this help. Thanks for your time. -Nico -- 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] install-interface-includes topic
On 07/29/2013 06:39 AM, Stephen Kelly wrote: So, I don't think it should be an error to specify INCLUDE DESTINATION without EXPORT. After all, I can specify LIBRARY DESTINATION for executables... Okay, that makes sense. Yes, I think we can leave out the error. -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] Introducing the ${Foo_TARGETS} variable (IntroduceTARGETSVariable branch)
On 07/26/2013 04:17 PM, Alexander Neundorf wrote: This should make sure that using this variable in a tll() call should suffice to give the target the required include dirs and libraries. Sounds good! I propose the name Foo_LIBRARY_TARGETS instead because the intended use case is only for libraries. KCoreAddons_TARGETS set by it lists the following non-existant targets: Foo s/existant/existent/ * Should the variable be mentioned in the documentation for find_package() ? Yes, since it is this command that enforces the error messages. * There is the theoretical risk that there are Config.cmake files out there which set a variable with that name already, but without the include dir property. Should this be based on a policy, so that the error is only generated if cmake 2.8.12 or higher is required ? I think with the name pkg_LIBRARY_TARGETS the risk is small. 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] Introducing the ${Foo_TARGETS} variable (IntroduceTARGETSVariable branch)
Alexander Neundorf wrote: So it can be used in tll() calls to link against the library (package). What makes it differ from Foo_LIBRARIES, is that CMake checks that each of the items listed in this variable * is an existing target * has the INTERFACE_INCLUDE_DIRS property set. Are you really certain it is always an error for a target to not set this? Comments ? If possible, I'd like to get that into 2.8.12. I'm still planning on getting the 'double colons for IMPORTED targets' feature in, but after 2.8.12. This is orthogonal, but the motivation is similar. My preference is to get a 2.8.12 out soon and open up for features after that. I have a few waiting for that already. 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] FindBacktrace.cmake
On 07/29/2013 04:59 AM, Vadim Zhukov wrote:
Thank you, Alexander. I've fixed both points you've mentioned and
merged the add-cmake_reset_check_state branch into the next.
Let's complete the add-cmake_reset_check_state topic first and
then you can rebase the find_backtrace topic on it to use the
feature. The former looks good but we'll let it run through the
dashboards tonight first.
One comment on the latter topic:
+ # Prepend list with library path as it's more common practice
+ set(_Backtrace_STD_ARGS Backtrace_LIBRARIES ${_Backtrace_STD_ARGS})
The FPHSA macro should be given Backtrace_LIBRARY since that is
what the user might modify, no?
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 0014319]: Access before VARIABLE_WATCH crashes GUI on second Configure
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=14319 == Reported By:Peter Boettcher Assigned To: == Project:CMake Issue ID: 14319 Category: QtDialog Reproducibility:always Severity: crash Priority: normal Status: new == Date Submitted: 2013-07-29 10:42 EDT Last Modified: 2013-07-29 10:42 EDT == Summary:Access before VARIABLE_WATCH crashes GUI on second Configure Description: Repeatable qt-dialog crash: set a variable, then add a watch. On second and following Configure (in the same session), the set() accesses invalid memory, and crashes the GUI about 20% of the time. valgrind shows the bad access on every run after the first. Analysis: The VARIABLE_WATCH command object itself is used as the client_data for the cmVariableWatchCommandVariableAccessed callback function, but the WatchCommand data structures do not own this data. When a second Configure is run, the generator is torn down, which deletes the cmVariableWatchCommand object. The list of watches is not deleted however, so the next SET() triggers the watch and tries to access the deleted cmVariableWatchCommand through the callback data. Steps to Reproduce: CMakeLists.txt: SET(MYVAR 0) VARIABLE_WATCH(MYVAR) Run cmake-gui and click Configure until crash. Or, run cmake-gui in valgrind, and watch for invalid access on second Configure. Additional Information: Repeatable on at least Linux with Makefiles, and Windows with Visual Studio generator. == Issue History Date ModifiedUsername FieldChange == 2013-07-29 10:42 Peter BoettcherNew Issue == -- 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] FindBacktrace.cmake
2013/7/29 Brad King brad.k...@kitware.com:
On 07/29/2013 04:59 AM, Vadim Zhukov wrote:
Thank you, Alexander. I've fixed both points you've mentioned and
merged the add-cmake_reset_check_state branch into the next.
Let's complete the add-cmake_reset_check_state topic first and
then you can rebase the find_backtrace topic on it to use the
feature. The former looks good but we'll let it run through the
dashboards tonight first.
Thank you for looking in. I'll follow this plan then.
One comment on the latter topic:
+ # Prepend list with library path as it's more common practice
+ set(_Backtrace_STD_ARGS Backtrace_LIBRARIES ${_Backtrace_STD_ARGS})
The FPHSA macro should be given Backtrace_LIBRARY since that is
what the user might modify, no?
Yep, you're right. I've just pushed the fix to stage.
--
WBR,
Vadim Zhukov
--
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] Weekly IRC Developer Chat
I will be holding a developer chat in the cmake irc channel starting at 2pm est, or 18:00 gmt. Server: freenode Channel: #cmake For those without an irc client: http://webchat.freenode.net/ -- 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] Introducing the ${Foo_TARGETS} variable (IntroduceTARGETSVariable branch)
On Monday 29 July 2013, Stephen Kelly wrote: Alexander Neundorf wrote: So it can be used in tll() calls to link against the library (package). What makes it differ from Foo_LIBRARIES, is that CMake checks that each of the items listed in this variable * is an existing target * has the INTERFACE_INCLUDE_DIRS property set. Are you really certain it is always an error for a target to not set this? I think so. If I want to use symbols from a library, I should include its headers, and for that the include dirs need to be known. For header-only libraries even more. Are there cases where this is not the case ? Don't know about Fortran. Alex -- 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] Introducing the ${Foo_TARGETS} variable (IntroduceTARGETSVariable branch)
On Monday 29 July 2013, Brad King wrote: On 07/26/2013 04:17 PM, Alexander Neundorf wrote: This should make sure that using this variable in a tll() call should suffice to give the target the required include dirs and libraries. Sounds good! I propose the name Foo_LIBRARY_TARGETS instead because the intended use case is only for libraries. I already thought the same, that this thing is not for all imported targets, i.e. plugins, executables and libraries, but only for libraries. It's juts a bit long. Personally I'm undecided. Probably being more correct is the better choice in this case. So, is your proposal just an alternative to think about or do you feel strongly that it should be this way ? KCoreAddons_TARGETS set by it lists the following non-existant targets: Foo s/existant/existent/ * Should the variable be mentioned in the documentation for find_package() ? Yes, since it is this command that enforces the error messages. I pushed that to the branch on stage. I guess you'll want to have a look at it, it can probably be improved. :-) Alex -- 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] Introducing the ${Foo_TARGETS} variable (IntroduceTARGETSVariable branch)
On 07/29/2013 04:10 PM, Alexander Neundorf wrote: On Monday 29 July 2013, Stephen Kelly wrote: Are you really certain it is always an error for a target to not set this? I think so. If I want to use symbols from a library, I should include its headers, and for that the include dirs need to be known. For header-only libraries even more. Are there cases where this is not the case ? Don't know about Fortran. Not all targets provided in a package need to be listed by the package config file in the pkg_LIBRARY_TARGETS variable. The restriction here is that those that are listed in the variable need to have INTERFACE_INCLUDE_DIRS set, even if empty. -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] Introducing the ${Foo_TARGETS} variable (IntroduceTARGETSVariable branch)
On 07/29/2013 04:41 PM, Alexander Neundorf wrote: Personally I'm undecided. Probably being more correct is the better choice in this case. So, is your proposal just an alternative to think about or do you feel strongly that it should be this way ? I'd prefer the more precise name. I guess you'll want to have a look at it, it can probably be improved. :-) I'll take a look when I get a chance. 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] Introducing the ${Foo_TARGETS} variable (IntroduceTARGETSVariable branch)
On Monday 29 July 2013, Brad King wrote: On 07/29/2013 04:41 PM, Alexander Neundorf wrote: Personally I'm undecided. Probably being more correct is the better choice in this case. So, is your proposal just an alternative to think about or do you feel strongly that it should be this way ? I'd prefer the more precise name. I guess you'll want to have a look at it, it can probably be improved. :-) I'll take a look when I get a chance. Thanks. This is now in the IntroduceLIBRARY_TARGETSVariable branch. Alex -- 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
