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
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
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.
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
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,
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 amend
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
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 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*
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
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
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
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 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
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
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. Please
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
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
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
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
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:
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 directory
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.
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
configure a
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)
...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
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.
This
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 STRING_EQUAL string)
if(string STRING_MATCHES regex)
...i.e., not mentioning variable anywhere for these
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
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: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 still
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
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
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
34 matches
Mail list logo
