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
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
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
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
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
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
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
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
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
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
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
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
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=14319
==
Reported By:Peter Boettcher
Assigned To:
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
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
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
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
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
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
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
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,
21 matches
Mail list logo
