[cfe-dev] patch: improving the add_clang_unittest() CMake function, and using it to add a target for unittests/Basic
Zhanyong Wan (λx.x x)
wan at google.com
Thu Feb 17 13:55:45 PST 2011
2011/2/17 Jeffrey Yasskin <jyasskin at google.com>:
> On Thu, Feb 17, 2011 at 12:10 PM, Zhanyong Wan (λx.x x) <wan at google.com> wrote:
>> 2011/2/17 Jeffrey Yasskin <jyasskin at google.com>:
>>> On Tue, Feb 15, 2011 at 9:01 PM, Zhanyong Wan (λx.x x) <wan at google.com> wrote:
>>>> I think a space-separated string is easier to parse (for a human
>>>> reader) than a semicolon-separated one, as it makes the boundary of
>>>> each word very obvious, especially with monospace fonts. If you are
>>>> fine with it, I'd like to go with the current version.
>>> dgregor suggested http://www.itk.org/Wiki/CMakeMacroParseArguments for
>>> making these arguments easier to read.
>> Interesting. I fear that it can be more confusing than helpful, as
>> there's no strong syntactical distinction between the parameter names
>> and their values -- they are all just a token in the argument list.
> CMake uses the [KEYWORDS introduce a LIST of arguments] convention in
> lots of other places,
Then it's different. But why did CMake choose this hack over
supporting list literal arguments properly? ;)
(It's not a question for you, I know.)
In general, I don't like mixing data and meta data. I think it will
be really confusing when some of the arguments happen to be in
UPPER_CASE (e.g. AST).
> so I think people need to get over that
> confusion anyway. It's definitely better than the system this patch
> introduced, which caused Bigcheese to suggest that I remove a
> positional argument when I reduced it to an empty string.
Perhaps we can use a mix of both approaches?
"USE_LIBS Basic Frontend"
More information about the cfe-dev