On 09/11/2014 03:40 PM, Nils Gladitz wrote:
> I think I've got it rewritten properly
Yes, it looks good!
Thanks,
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the C
I think I've got it rewritten properly but I didn't know what half the
git commands I ran did most of the time so I am not entirely secure with
the result.
Would have probably not figured this out without your help.
Thanks again!
Nils
--
Powered by www.kitware.com
Please keep messages on-top
On 11.09.2014 19:14, Brad King wrote:
On 09/11/2014 01:07 PM, Nils Gladitz wrote:
I would have to add back lines to cmConditionEvaluator.cxx which where
removed while they were still in cmIfCommand.cxx.
Look at the diff in commit 5922fc2c and you will see all those lines as
removed from cmIfCom
On 09/11/2014 01:07 PM, Nils Gladitz wrote:
> I would have to add back lines to cmConditionEvaluator.cxx which where
> removed while they were still in cmIfCommand.cxx.
Look at the diff in commit 5922fc2c and you will see all those lines as
removed from cmIfCommand. You can put them all in cmCon
On 11.09.2014 18:59, Brad King wrote:
At this point cmConditionEvaluator.cxx exists in the source tree.
What is the problem?
I can not create a CMP0054 free version of cmConditionEvaluator.cxx by
simply removing content from the file (or the patch).
I would have to add back lines to cmConditio
On 09/11/2014 12:57 PM, Nils Gladitz wrote:
>> Then keep editing the files and amending the commit to leave
>> behind only the refactoring pieces.
>
> That is the part I was stuck at.
At this point cmConditionEvaluator.cxx exists in the source tree.
What is the problem?
-Brad
--
Powered by ww
On 11.09.2014 18:53, Brad King wrote:
On 09/11/2014 11:52 AM, Nils Gladitz wrote:
cmConditionEvaluator.cxx doesn't exist without the CMP0054 changes
because I created it after I did most of the CMP0054 changes.
Since most of the changes are replacements rather than plain additions
*removing* tho
On 09/11/2014 11:52 AM, Nils Gladitz wrote:
> cmConditionEvaluator.cxx doesn't exist without the CMP0054 changes
> because I created it after I did most of the CMP0054 changes.
> Since most of the changes are replacements rather than plain additions
> *removing* those changes would mean having to
On 11.09.2014 17:39, Brad King wrote:
On 09/11/2014 11:35 AM, Nils Gladitz wrote:
Thanks for the walk through.
I am a bit stuck on removing the CMP0054 changes from
cmConditionEvaluator.cxx part given that file is new and didn't exist
without the changes.
The file should exist, just remove the
On 09/11/2014 11:35 AM, Nils Gladitz wrote:
> Thanks for the walk through.
>
> I am a bit stuck on removing the CMP0054 changes from
> cmConditionEvaluator.cxx part given that file is new and didn't exist
> without the changes.
The file should exist, just remove the CMP0054 parts from it
and am
On 11.09.2014 15:28, Brad King wrote:
First rewrite the branch to squash your updates back into
the first commit, leaving all my CMP0054 warning commits
later in the topic. Then start a new branch from the
squashed commit containing only your part of the changes.
Note the sha1 of this commit, sa
On 09/11/2014 09:20 AM, Nils Gladitz wrote:
> Is there a trick to recreate the history in that order or
> would I have to start from scratch?
First rewrite the branch to squash your updates back into
the first commit, leaving all my CMP0054 warning commits
later in the topic. Then start a new bra
On 11.09.2014 15:04, Brad King wrote:
Good work. I think the net change is now in good shape. To make it
easier to review now and bisect in the future, please rewrite the
topic to start with refactoring cmIfCommand to split out the
cmConditionEvaluator, and then add the rest of the changes.
T
On 09/10/2014 03:42 PM, Nils Gladitz wrote:
> extract everything into its own class "cmConditionEvaluator" and have it
> keep everything that was being passed around as members instead.
Good work. I think the net change is now in good shape. To make
it easier to review now and bisect in the fut
On 09/10/2014 05:33 PM, Brad King wrote:
Thanks. I've updated the topic to include all the actual fixes
for CMP0054 warnings within CMake's own code that I've found so
far.
Thanks!
I have a few more changes to request that you add to the topic:
* The wording of the warning says what the cha
On 09/08/2014 11:35 AM, Nils Gladitz wrote:
> I updated the topic, squished and merged.
Thanks. I've updated the topic to include all the actual fixes
for CMP0054 warnings within CMake's own code that I've found so
far.
I have a few more changes to request that you add to the topic:
* The wordi
On 09/08/2014 04:44 PM, Brad King wrote:
Good work on the revisions.
Thanks.
I updated the topic, squished and merged.
Nils
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to suppor
On 09/05/2014 09:19 AM, Nils Gladitz wrote:
> On 09/05/2014 02:50 PM, Brad King wrote:
>> On 09/04/2014 11:58 AM, Nils Gladitz wrote:
>> - The dashboard submissions that bootstrap got many CMP0054
>>warnings. Most of them are the same warning repeated due
>>to presence in a macro or loop.
On 09/05/2014 10:17 AM, Nils Gladitz wrote:
>>> On 09/05/2014 03:31 PM, Brad King wrote:
>>
>> I think the description of RunCMake can just be updated.
>> All of its tests are about running "cmake" command lines.
>
> So you see no advantage to having the distinction?
>
> E.g. if you consider test
...I would prefer to combine into something more compact.The other
infrastructure I don't think I have touched but optically it looks
very noisy.Having something that takes away repetitive tasks, more
compact and easier on the eye would be nice.
I agree. That would be nice. Feel free to reinvent
On 09/05/2014 03:31 PM, Brad King wrote:
I think the description of RunCMake can just be updated.
All of its tests are about running "cmake" command lines.
So you see no advantage to having the distinction?
E.g. if you consider testing a set of generators (or variants of the
same generator)
On 09/05/2014 09:50 AM, Nils Gladitz wrote:
> On 09/05/2014 03:31 PM, Brad King wrote:
>> You can use "run_cmake_command" to run arbitrary cmake command-line
>> signatures and still use the rest of the infrastructure.
>
> Ok. I just thought it would be nice to distinguish tests that don't
> confi
On 09/05/2014 03:33 PM, David Cole wrote:
I was also thinking about setting up an alternative testing
infrastructure parallel to RunCMake which runs cmake in script mode
rather than performing configuration/generation.
This already exists in a form in the Tests/CMakeTests/*TestScript*
tests.
A
On 09/05/2014 03:31 PM, Brad King wrote:
You can use "run_cmake_command" to run arbitrary cmake command-line
signatures and still use the rest of the infrastructure.
Ok. I just thought it would be nice to distinguish tests that don't
configure a project. (Headline for RunCMake is "This directo
I was also thinking about setting up an alternative testing
infrastructure parallel to RunCMake which runs cmake in script mode
rather than performing configuration/generation.
This already exists in a form in the Tests/CMakeTests/*TestScript*
tests.
An example:
http://www.cmake.org/gitweb?p=cm
On 09/05/2014 09:19 AM, Nils Gladitz wrote:
> Would it be ok to set the policy for cmcurl to OLD?
No, but the code could be fixed to not trigger the warning.
See similar changes here:
Check*: Allow result variables to contain regex special characters
http://cmake.org/gitweb?p=cmake.git;a=commit
On 09/05/2014 02:50 PM, Brad King wrote:
On 09/04/2014 11:58 AM, Nils Gladitz wrote:
- The dashboard submissions that bootstrap got many CMP0054
warnings. Most of them are the same warning repeated due
to presence in a macro or loop. Please update the warning
to not warn on the same li
On 09/04/2014 11:58 AM, Nils Gladitz wrote:
> Thanks, that actually sounds doable.
>
> I'll give it a try.
Good work on the topic so far. I have a few more thoughts:
- The dashboard submissions that bootstrap got many CMP0054
warnings. Most of them are the same warning repeated due
to pres
On 09/04/2014 05:53 PM, Brad King wrote:
Most commands just implement InitialPass, which gets the expanded
arguments. Some implement InvokeInitialPass which gets the args
before expansion. The cmIfCommand does this already, and its
call to cmMakefile::ExpandArguments could be updated to request
On 09/04/2014 11:41 AM, Nils Gladitz wrote:
> I assume the fact that arguments were quoted would have to be preserved
> and the implementation of all existing commands touched so that they can
> actually make use of that information (even if only if() would currently
> make use of it).
Most com
On 09/04/2014 05:13 PM, Brad King wrote:
As I have explained every other time it has come up there is exactly
one way to fix it: a policy that makes expansion happen only for
unquoted arguments. Someone just has to do it.
The fact that this behaviour has persisted this long and that no one ha
On 09/04/2014 10:51 AM, Nils Gladitz wrote:
> I am rather used to "if()" as well but safe_if()/if_noexpand() might
> still be more readable than the workarounds that people are using now to
> get something close to the expected behavior with regular if() [1].
If "if()" is never fixed people will
On 09/04/2014 04:40 PM, Brad King wrote:
On 09/04/2014 10:25 AM, Nils Gladitz wrote:
I think a new command would ("if_noexpand") would make the "correct"
code less readable than the "incorrect" code. Also the implicit-bool
conversion of variables is more readable IMO; consider
if(${FOO_FOUND}
On 09/04/2014 10:25 AM, Nils Gladitz wrote:
> This keeps coming up and there probably have been many discussions on
> how this might be "fixed" as well.
As I have explained every other time it has come up there is exactly
one way to fix it: a policy that makes expansion happen only for
unquoted a
Another approach might be to add STRING_EQUAL and STRING_MATCHES (or
similarly unambiguous names) operators that do not do the variable
lookup.
The documentation would start with:
if( STRING_EQUAL )
if( STRING_MATCHES )
...i.e., not mentioning anywhere for these operators.
D
--
Powered by w
This keeps coming up and there probably have been many discussions on
how this might be "fixed" as well.
I am wondering if we could provide an alias for the "if" command (e.g.
"safe_if") that would inherit cmIfCommand but would reimplement
GetVariableOrString() without the variable lookup.
T
36 matches
Mail list logo
