On 09/24/2012 09:23 AM, Brad King wrote:
> On 09/24/2012 09:15 AM, Stephen Kelly wrote:
>> I also want to obsolete the IMPORTED_LINK_INTERFACE_LIBRARIES in favor
>> of INTERFACE_LINK_LIBRARIES so that expressions such as
>>
>> $
>>
>> work for every target, not just non-imported ones. I'm not re
On 09/24/2012 09:15 AM, Stephen Kelly wrote:
> I also want to obsolete the IMPORTED_LINK_INTERFACE_LIBRARIES in favor
> of INTERFACE_LINK_LIBRARIES so that expressions such as
>
> $
>
> work for every target, not just non-imported ones. I'm not really sure why
> the IMPORTED_ variants of thos
Brad King wrote:
>> The only option I see that might work is to extend the undefined behavior
>> documentation of the LOCATION* properties to cover use of generator
>> expressions with link libraries, and then try to refactor/copy the code
>> out of cmTarget to cmGeneratorTarget to add the generato
On 09/24/2012 04:42 AM, Stephen Kelly wrote:
> get_target_property(loc tgt LOCATION)
> get_target_property(loc tgt LOCATION_${Config})
[snip]
> It seems that the generator expressions for linked targets is in conflict
> with the 'linker preference' feature. Is this a resolvable situation?
That
Stephen Kelly wrote:
> Brad King wrote:
It should be in cmTarget::ComputeLinkImplementation at this line:
>>
>> If it is not that early then we need to consider the interaction
>> of at least these pieces:
>>
>>cmTarget::GetLinkerLanguage
>>cmTarget::GetLinkClosure
>>cmTarget::ComputeLinkClos
Brad King wrote:
>> I'll do the revert-in-next+rebase+re-merge-to-next later today unless
>> there's an objection.
>
> I did the rebase/squash yesterday. In order to make the result cleaner
> and identical to the original net change on the topic I wanted to add
> one commit to it. I needed that
On 09/19/2012 04:17 AM, Stephen Kelly wrote:
> Brad King wrote:
>
>>> I think it would make sense to rewrite the branch to squash the
>>> whitespace fixes before merging to master though.
>>
>> Yes, I can do this when the topic is done.
>>
>
> I saw that it didn't get into master yesterday. Does
Brad King wrote:
>> I think it would make sense to rewrite the branch to squash the
>> whitespace fixes before merging to master though.
>
> Yes, I can do this when the topic is done.
>
I saw that it didn't get into master yesterday. Does this mean it won't get
in until next week?
If that is
Brad King wrote:
> when either nameQual or dirQual is true that is a compile-time constant
> so the "return result" line is truly unreachable in that instantiation.
Yes. I was assuming a compiler optimization would exist for that kind of
thing.
> You need to use compile-time conditional code rat
On 09/17/2012 08:50 AM, Stephen Kelly wrote:
> I've fixed all errors and warnings that can be fixed. Some remain due to
> compiler bugs which claim some code in a template is unreachable (but that's
> only due to the template parameters).
The HP warnings are not a compiler bug. It looks like ot
Stephen Kelly wrote:
> too. That should be three trivial patches, but I haven't written them yet.
> That's all I'm aiming for of the target_use_targets feature for the next
> release, so I think that's still on track.
I spoke too soon. It's 3 trivial patches and one DAG-checker. :)
http://commun
Stephen Kelly wrote:
>>> The next thing I want to do is to see if I can make full use of
>>> cmGeneratorTarget and use const proactively while doing so, to make the
>>> code more clear. I'm not 100% certain that's possible, but it's the next
>>> goal I have. Any comments on that?
>>
>> That would
Stephen Kelly wrote:
> Good idea. Pushed to next with this modification.
>
I've fixed all errors and warnings that can be fixed. Some remain due to
compiler bugs which claim some code in a template is unreachable (but that's
only due to the template parameters).
I think it would make sense to
Stephen Kelly wrote:
>> The destructor of cmCompiledGeneratorExpression is deleting
>> the evaluators before they get used again in later evals.
>> Commenting out the "delete" line fixes the crash but probably
>> leaks. You need to work out the ownership semantics.
>>
>
> Thanks. I'm too used to
On 9/13/2012 1:10 PM, David Cole wrote:
If Steve hadn't fixed it already, it would have been a nightmare for
tomorrow's dashboards...:-)
OK, I see...
Hard to tell, but has this been addressed:
http://open.cdash.org/viewBuildError.php?buildid=2561866
c:\dashboards\my
tests\ninjacmake\source\c
It wasn't merged into 'next' until 3:53 am this morning. It only shows
up on dashboards run after that, which are not snapped to 'nightly'...
This merge commit is the first time it went to 'next'
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f315bcb5f34e54e5ab2bc6560323aaca7df77a2a
If Steve
On 9/13/2012 12:44 PM, Stephen Kelly wrote:
Thanks. I'm too used to everything being implicitly shared:). Valgrind
didn't show the problem, interestingly enough.
Odd, it does not show up in the coverage either?
--
Bill Hoffman
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065
bill.hoff...
Brad King wrote:
> On 09/13/2012 10:34 AM, Stephen Kelly wrote:
>> I'm getting errors that I can't investigate:
>>
>> http://open.cdash.org/viewTest.php?onlydelta&buildid=2561961
>>
>> I find it surprising that the windows builds segfault on this while the
>> linux ones dont. The code paths are
On 09/13/2012 10:34 AM, Stephen Kelly wrote:
> I'm getting errors that I can't investigate:
>
> http://open.cdash.org/viewTest.php?onlydelta&buildid=2561961
>
> I find it surprising that the windows builds segfault on this while the
> linux ones dont. The code paths are not different.
The destr
Stephen Kelly wrote:
>
> Pushed to next with this modification.
>
I'm getting errors that I can't investigate:
http://open.cdash.org/viewTest.php?onlydelta&buildid=2561961
The segfaults make it so that there is no output visible from the tests.
I find it surprising that the windows builds seg
Brad King wrote:
> On 09/12/2012 11:36 AM, Stephen Kelly wrote:
>> I've force-pushed the generator-expression-refactor branch to my
>> gitorious clone.
>
> Great progress!
>
> One thing that bothers me about the current design is that the
> cmGeneratorExpression instances now have more states.
On 09/12/2012 11:36 AM, Stephen Kelly wrote:
> I've force-pushed the generator-expression-refactor branch to my gitorious
> clone.
Great progress!
One thing that bothers me about the current design is that the
cmGeneratorExpression instances now have more states. This
pattern appears everywher
Brad King wrote:
>> So now that we've agreed on the language, and unless I've missed
>> something, I'll refactor that code to use helper methods rather than
>> helper classes and generally clean up and rewrite the branch.
>
> Sounds good.
>
I've force-pushed the generator-expression-refactor br
On 09/03/2012 01:05 PM, Stephen Kelly wrote:
> With the CMake generator expressions, I don't know the nodes at parse time,
[smacks forehead]
> So now that we've agreed on the language, and unless I've missed something,
> I'll refactor that code to use helper methods rather than helper classes a
Brad King wrote:
> On 08/31/2012 07:21 AM, Stephen Kelly wrote:
>> The above is not necessary. It can instead be literally:
>>
>> "$<$:-Wl,no-undefined>"
>> "$<$,$,b>>:-Wl,no-
undefined>"
>>
>> The comma is ambiguous to the parser, but not to the generator
>> expression. I've updated my -ref
On 08/31/2012 07:21 AM, Stephen Kelly wrote:
> The above is not necessary. It can instead be literally:
>
> "$<$:-Wl,no-undefined>"
> "$<$,$,b>>:-Wl,no-undefined>"
>
> The comma is ambiguous to the parser, but not to the generator expression.
> I've updated my -refactor branch to deal with i
I realised that what I wrote yesterday was not completely correct:
Stephen Kelly wrote:
>>> set_target_properties(foolib
>>>PROPERTIES COMPILE_OPTIONS
>>>"$<$:-Wl$no-undefined>"
>>> )
>>
>> That is a good example of a reason not to use comma for separation.
The above is not necessary. It can ins
On 08/30/2012 11:55 AM, Stephen Kelly wrote:
> From earlier:
>> One way to distinguish expressions with free-form arguments from
>> those without is whether there is a ':' or whitespace after the
>> expression name.
>
> This isn't very clear to me. Should ':' be part of the syntax which is
> alwa
Brad King wrote:
> The entire expression must still be quoted and have its internal syntax
> escaped through the CMake language. We could use single quotes instead:
>
> set_property(TARGET foolib
>[APPEND] PROPERTY INCLUDE_DIRECTORIES
>"$<$ '/bar bat/bag'>"
>)
>
> for quoting inside
On 08/30/2012 04:33 AM, Stephen Kelly wrote:
> Other examples:
>
> $
>
> $
>
> Which looks like a fairly 'normal' escaping scheme from a c++ point of view.
Yes.
> because that set_target_properties signature can only take one argument
> (there are other bug reports about this I think, but I d
Brad King wrote:
> On 08/29/2012 09:25 AM, Brad King wrote:
>>> I've pushed a generator-expression-refactor branch to my clone. It needs
>>> some clean-up, de-duplication etc, but I'm looking for feedback on the
>>> approach.
>>>
>>> In my branch, all parameters must be separated by ','. All comma
Brad King wrote:
> On 08/27/2012 05:38 AM, Stephen Kelly wrote:
>> Yes, I can see how the language could be able to offer both. However, I
>> do think that the built-in 'this' target should be the one that the
>> generator expression is evaluated on.
>
> Okay. I'd just like to reserve room in th
On 08/29/2012 09:25 AM, Brad King wrote:
>> I've pushed a generator-expression-refactor branch to my clone. It needs
>> some clean-up, de-duplication etc, but I'm looking for feedback on the
>> approach.
>>
>> In my branch, all parameters must be separated by ','. All commas and colons
>> must a
On 08/27/2012 05:38 AM, Stephen Kelly wrote:
> Yes, I can see how the language could be able to offer both. However, I do
> think that the built-in 'this' target should be the one that the generator
> expression is evaluated on.
Okay. I'd just like to reserve room in the syntax to allow the tar
Stephen Kelly wrote:
>
> The STREQUAL expression also makes the CONFIG expression redundant and
> equivalent to $,...>. I can see reason to keep
> CONFIG anyway because it is more convenient and is expected to be commonly
> used I think.
Actually, a good reason to keep the CONFIG expression is to
Brad King wrote:
> On 08/22/2012 06:12 PM, Stephen Kelly wrote:
>>> of linking there are multiple targets involved so we do not know
>>> which one the user may mean.
>>
>> I think it's something we can just define, is it not?
>
> Some expressions might want the target being linked while others m
On 08/22/2012 06:12 PM, Stephen Kelly wrote:
>> of linking there are multiple targets involved so we do not know
>> which one the user may mean.
>
> I think it's something we can just define, is it not?
Some expressions might want the target being linked while others may
want the target in which
Brad King wrote:
>>> It should be in cmTarget::ComputeLinkImplementation at this line:
>
> If it is not that early then we need to consider the interaction
> of at least these pieces:
>
> cmTarget::GetLinkerLanguage
> cmTarget::GetLinkClosure
> cmTarget::ComputeLinkClosure
> cmTarget::GetLink
On 08/20/2012 04:25 PM, Stephen Kelly wrote:
> I've implemented it like that now. That will also work for
> compile_definitions, but I think it won't work for link_libraries. I'm also
> not sure about link_directories, compiler_flags and linker_flags. For
> link_libraries it is quite unfortunate
Brad King wrote:
> On 08/19/2012 05:43 PM, Stephen Kelly wrote:
>> Thanks, here are my findings so far, which relate to my extension of that
>> branch at
>> g...@gitorious.org:~steveire/cmake/steveires-
cmake.git:
>
> Thanks for working on this.
Thanks for the feedback. I've updated the branch.
On 08/19/2012 05:43 PM, Stephen Kelly wrote:
> Thanks, here are my findings so far, which relate to my extension of that
> branch at g...@gitorious.org:~steveire/cmake/steveires-cmake.git:
Thanks for working on this.
> 1) The result string of the $ expression does not allow lists.
> That means
Stephen Kelly wrote:
> 1) The result string of the $ expression does not allow lists.
> That means we can't do anything like this:
I just realized that this isn't really anything to do with the $
in particular, but a more general issue which is addressed by the patch to
ExpandListArgument.
Than
Brad King wrote:
> On 08/14/2012 05:11 AM, Stephen Kelly wrote:
>> Thanks, I'll see what I can figure out.
>>
>> I think at this point, I'm more interested in linking to a library based
>> on the content of a target property (ie, linking QT_QTMAIN_LIBRARY based
>> on whether WIN32_EXECUTABLE is s
On 08/14/2012 05:11 AM, Stephen Kelly wrote:
> Thanks, I'll see what I can figure out.
>
> I think at this point, I'm more interested in linking to a library based on
> the content of a target property (ie, linking QT_QTMAIN_LIBRARY based on
> whether WIN32_EXECUTABLE is set), so I may need to
Brad King wrote:
> On 06/11/2012 11:27 AM, Brad King wrote:
>> I've started a local topic branch and implemented $<0:...>,
>> $<1:...>, and $. When I get a chance I'll add
>> some of the other queries, documentation, and tests for the
>> generator expression features.
>
> I've been making occasi
On 06/11/2012 11:27 AM, Brad King wrote:
> I've started a local topic branch and implemented $<0:...>,
> $<1:...>, and $. When I get a chance I'll add
> some of the other queries, documentation, and tests for the
> generator expression features.
I've been making occasional progress on this. This
On 06/07/2012 05:47 PM, Stephen Kelly wrote:
> Brad King wrote:
>> cmGeneratorExpression::Evaluate can be taught to handle everything
>> pretty easily.
>>
>> Then more places need to be taught to pass values through instances
>> of cmGeneratorExpression, such as the INCLUDE_DIRECTORIES property
>>
Brad King wrote:
> On 06/07/2012 01:25 PM, Stephen Kelly wrote:
>> Although the questions are rhetorical, I'll answer them anyway to clarify
>> the intention of the proposal. I'm not trying to push my proposal, but I
>> want to make sure it's understood :).
>
> The reason I said they're rhetorica
On 06/07/2012 01:25 PM, Stephen Kelly wrote:
> Although the questions are rhetorical, I'll answer them anyway to clarify
> the intention of the proposal. I'm not trying to push my proposal, but I
> want to make sure it's understood :).
The reason I said they're rhetorical is I'm not interested i
Brad King wrote:
> On 06/07/2012 11:41 AM, Stephen Kelly wrote:
>> Brad King wrote:
>>> On 06/05/2012 04:59 PM, Stephen Kelly wrote:
generator_expression(myGenExpr)
>>>
>>> That is an interesting idea to keep in mind for the future but I think
>>> the implementation of it is too tricky to be
On 06/07/2012 11:41 AM, Stephen Kelly wrote:
> Brad King wrote:
>> On 06/05/2012 04:59 PM, Stephen Kelly wrote:
>>> generator_expression(myGenExpr)
>>
>> That is an interesting idea to keep in mind for the future but I think
>> the implementation of it is too tricky to be in scope now.
>
> That's
Brad King wrote:
> On 06/05/2012 04:59 PM, Stephen Kelly wrote:
>> So far we don't have agreement about how this should look language-wise
>> as far as I can tell. I agree with David that stuffing it into the
>> strings harms readability.
> [snip]
>> generator_expression(myGenExpr)
> [snip]
>> The
On 06/05/2012 04:59 PM, Stephen Kelly wrote:
> So far we don't have agreement about how this should look language-wise as
> far as I can tell. I agree with David that stuffing it into the strings
> harms readability.
[snip]
> generator_expression(myGenExpr)
[snip]
> The $ could similarly be used
Brad King wrote:
> On 05/25/2012 05:18 PM, Stephen Kelly wrote:
>> By the way, another thing we would need to cover with this is linking to
>> another library based on the value of a property.
>>
>> https://codereview.qt-project.org/#change,26577
>
> That one doesn't have to be delayed until gen
On 05/25/2012 05:18 PM, Stephen Kelly wrote:
> By the way, another thing we would need to cover with this is linking to
> another library based on the value of a property.
>
> https://codereview.qt-project.org/#change,26577
That one doesn't have to be delayed until generation time, but if we
di
Stephen Kelly wrote:
> if ("${CMAKE_C_COMPILER_ID} ${CMAKE_CXX_COMPILER_ID}" MATCHES SunPro)
> list(APPEND additional_INCLUDE_DIRECTORIES "/bar/some_sunpro_hack")
> endif ()
>
Oops. Obviously I should have has a
set_property(TARGET ${_target}
APPEND PROPERTY
INCLUDE_DIRECTORIES
Brad King wrote:
> On 05/19/2012 04:45 PM, Alexander Neundorf wrote:
>> On Thursday 17 May 2012, David Cole wrote:
>>> I don't think this conditional stuff in generator expressions is a good
>>> idea at all.
>>
>> Me too ;-)
>
> The goal is to allow per-configuration/per-language/per-xyz values
On 05/19/2012 04:45 PM, Alexander Neundorf wrote:
> On Thursday 17 May 2012, David Cole wrote:
>> I don't think this conditional stuff in generator expressions is a good
>> idea at all.
>
> Me too ;-)
The goal is to allow per-configuration/per-language/per-xyz values to
appear in places like the
On Thursday 17 May 2012, David Cole wrote:
> I don't think this conditional stuff in generator expressions is a good
> idea at all.
>
> It's going to be ugly and very hard to read, and make people hate the CMake
> language even more than they already do.
I think I agree.
> If there's any way at
I don't think this conditional stuff in generator expressions is a good
idea at all.
It's going to be ugly and very hard to read, and make people hate the CMake
language even more than they already do.
If there's any way at all that supports what we want but does not require
conditionals, then we
On 05/17/2012 10:31 AM, Stephen Kelly wrote:
>> We may not need the "else" part but we still need a strict and extensible
>> syntax to delimit the value in the "..." part above.
>
> not certain what you have in mind with 'extensible' or if you have any ideas
> of how it might need to be extended.
61 matches
Mail list logo
