cmTarget: Refactor ComputeLinkImplementation (24637979):
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=24637979
Seems to have broken this reduced testcase:
cmake_minimum_required(VERSION 3.0)
set(LIBRARIES
foobar.lib
barfoo.lib
)
add_executable(foo foo.cpp)
On 08-Oct-14 16:45, Brad King wrote:
On 10/08/2014 07:52 AM, Ruslan Baratov wrote:
Okay :) I just not sure that I understand to pass to some other
process goal correctly.
That was just an example of why one might want to drop management
of the lock by CMake without actually unlocking it.
On 10/10/2014 01:10 PM, Nils Gladitz wrote:
Ninja on windows invokes the resource compiler through cmcldeps.
When passing ${CMAKE_BINARY_DIR} as an include directory CMake used to
(3.0) add the absolute path to the command line; now -I. is being
added instead.
The relative path does not seem
On 10/09/2014 10:58 AM, Eric Noulard wrote:
This message is an open request to find volunteer maintainers
for CPackRPM and CPackDeb
I did contribute to CMake/CPack for some time (~2007) now but
my CMake free time is now too small to be able to test and
integrate contribution/patches to
What is the main use case for locking files and directories from the
CMake language?
I feel slightly uncomfortable, without being able to put my finger on
exactly why, with the prospect of adding this to CMake...
Behavior when there's a lock that still exists (by bug/mistake) after
CMake is done
On 10/10/2014 05:09 AM, Nils Gladitz wrote:
set(LIBRARIES
foobar.lib
barfoo.lib
)
add_executable(foo foo.cpp)
target_link_libraries(foo PUBLIC $BUILD_INTERFACE:${LIBRARIES})
This is basically writing:
target_link_libraries(foo PUBLIC $BUILD_INTERFACE:foobar.lib
On 10/10/2014 03:14 PM, Brad King wrote:
I can work around this by wrapping the libraries with $BUILD_INTERFACE
individually or by quoting the entire genex.
This was the intended interface.
I'm willing to regress this because:
- It restores 2.8.12 behavior
- The quoting is easy to do
- It is
On 10-Oct-14 16:58, David Cole wrote:
What is the main use case for locking files and directories from the
CMake language?
I feel slightly uncomfortable, without being able to put my finger on
exactly why, with the prospect of adding this to CMake...
I've described the situation in the first
On 10/10/2014 04:11 PM, Brad King wrote:
Thanks, fixed and test added:
Ninja: Fix RC include directories regression
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=23c8eeb7
Thanks!
Nils
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
On 10/10/2014 10:18 AM, Nils Gladitz wrote:
As a side node for post-3.1 development it might be nice to have the
Ninja generator properly escape the $ from e.g. those broken generator
expressions that leak through or alternatively have CMake produce an
error during generation.
I think the
On 10/10/2014 09:17 AM, Nils Gladitz wrote:
On 10/10/2014 03:14 PM, Brad King wrote:
I will add mention of this in the 3.1 release notes.
Good enough for me, thanks!
Here is a release note entry:
Help: Add note about restoring pre-3.0 link libraries genex behavior
On 10/09/2014 11:19 AM, Brad King wrote:
I merged it for testing in 'next'.
Everything tested cleanly! Adam, Clinton, thanks for your help
bringing this topic to maturity. It was the last non-regression
topic I'm planning to take for 3.1. I squashed the fixes and
revised commit messages
Clinton Stimpson wrote:
Another justification for that is if a target does not link to any
libraries with an @rpath id, it is still useful to have an rpath to
support dlopen(@rpath/somelib).
Picking a message randomly, to respond to - Can someone tell me what this
comment is referring to?
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15203
==
Reported By:Lekensteyn
Assigned To:
14 matches
Mail list logo
