[cfe-dev] patch: improving the add_clang_unittest() CMake function, and using it to add a target for unittests/Basic

[Douglas Gregor]

On Feb 17, 2011, at 1:55 PM, Zhanyong Wan (λx.x x) wrote:

> 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).

You can always quote the arguments ("AST") to make it more obvious. Besides, all built-in CMake commands have the same issue, and I've never actually seen it cause any problems.

This point of using the macro to parse keyword arguments is that it makes user-defined macros look and act a lot more like built-in CMake commands. Doing something that's a little bit like CMake's keyword arguments but slightly different would be more confusing.


	- Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110217/ee03d3ba/attachment.html>