On 12/06/2013 04:42 PM, Matthew Woehlke wrote:
An advantage of keeping the name is that existing callers get the
speed-up immediately. Furthermore there will be less code left in the
old module to maintain.
I think that is still true if the module just wraps the new function?
Yes, I think
On 05/12/13 14:56, Brad King wrote:
Without a policy project authors will not be warned about the change in
behavior that would be caused by bumping cmake_minimum_required(VERSION).
Ok, let's assume that we add a C++ implementation with a CMP policy
that does
* OLD policy = SKIP_EMPTY
*
On 2013-12-06 14:51, Daniele E. Domenichelli wrote:
Are you sure you don't want the command to be renamed to
parse_arguments? The only commands containing cmake looks strictly
related to cmake, and the arguments parsing does not look that much
related...
FWIW, I was sort-of hoping it would be.
On 12/06/2013 02:51 PM, Daniele E. Domenichelli wrote:
If CMAKE_MINIMUM_REQUIRED_VERSION = 3.0.0, the NEW policy will be used,
but the author should also be warned that he should no longer include
the CMakeParseArguments.cmake file, since it will be deprecated and
might disappear in the
On 12/06/2013 03:11 PM, Matthew Woehlke wrote:
On 2013-12-06 14:51, Daniele E. Domenichelli wrote:
Are you sure you don't want the command to be renamed to
parse_arguments? The only commands containing cmake looks strictly
related to cmake, and the arguments parsing does not look that much
On 12/06/2013 02:51 PM, Daniele E. Domenichelli wrote:
Actually ExternalProject, like several other modules, would probably
benefit on using the C++ implementation instead of having their own
parsing, or using the cmake implementation, but that's for a following
patch.
The ExternalProject
On 12/04/2013 08:20 AM, Brad King wrote:
On 12/04/2013 04:57 AM, Daniele E. Domenichelli wrote:
+1, since this is a very useful feature.
Actually after thinking about this over night I realized that converting
to a C++ implementation is the best way to fix the empty argument handling
too.
