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
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 b
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 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 dir
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_TARGE
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
> >
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/opensou
2013/7/29 Brad King :
> 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 f
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
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=14319
==
Reported By:Peter Boettcher
Assigned To:
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 us
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/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
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.ki
On Mon, Jul 29, 2013 at 2:25 PM, Stephen Kelly 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 w
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 thin
On Mon, Jul 29, 2013 at 2:09 PM, Stephen Kelly wrote:
> Nicolas Desprès wrote:
>
> > On Mon, Jul 29, 2013 at 12:57 PM, Stephen Kelly
> > 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 ar
Nicolas Desprès wrote:
> On Mon, Jul 29, 2013 at 12:57 PM, Stephen Kelly
> 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.
On Mon, Jul 29, 2013 at 12:57 PM, Stephen Kelly 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
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.
>
Brad King wrote:
> Please add an error condition when INCLUDES DESTINATION is used
> without EXPORT and a test case to cover it.
I added that, but I think it would be better to remove the error case.
In KDE we have a INSTALL_TARGETS_DEFAULT_ARGS variable, used like this:
install(TARGETS klib1
2013/7/27 Alexander Neundorf :
> Hi,
>
> I pushed the IntroduceTARGETSVariable branch to stage.
>
> It introduces the new variable Foo_TARGETS to be used in Config files,
> additionally to or maybe better instead of Foo_LIBRARIES and Foo_INCLUDE_DIRS.
>
> This variable shall be used to list the tar
2013/7/28 Rolf Eike Beer :
> On Sun Jul 28 15:46:27 2013 Vadim Zhukov 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,
2013/7/29 Alexander Neundorf :
> Hi Vadim,
>
> On Sunday 28 July 2013, you wrote:
>> 2013/7/23 Alexander Neundorf :
>> > 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
>> >> > behavio
24 matches
Mail list logo
