<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Feb 17, 2011, at 1:55 PM, Zhanyong Wan (λx.x x) wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>2011/2/17 Jeffrey Yasskin <<a href="mailto:jyasskin@google.com">jyasskin@google.com</a>>:<br><blockquote type="cite">On Thu, Feb 17, 2011 at 12:10 PM, Zhanyong Wan (λx.x x) <<a href="mailto:wan@google.com">wan@google.com</a>> wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite">2011/2/17 Jeffrey Yasskin <<a href="mailto:jyasskin@google.com">jyasskin@google.com</a>>:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On Tue, Feb 15, 2011 at 9:01 PM, Zhanyong Wan (λx.x x) <<a href="mailto:wan@google.com">wan@google.com</a>> wrote:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I think a space-separated string is easier to parse (for a human<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">reader) than a semicolon-separated one, as it makes the boundary of<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">each word very obvious, especially with monospace fonts. If you are<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">fine with it, I'd like to go with the current version.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">dgregor suggested <a href="http://www.itk.org/Wiki/CMakeMacroParseArguments">http://www.itk.org/Wiki/CMakeMacroParseArguments</a> for<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">making these arguments easier to read.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Interesting. I fear that it can be more confusing than helpful, as<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">there's no strong syntactical distinction between the parameter names<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">and their values -- they are all just a token in the argument list.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">CMake uses the [KEYWORDS introduce a LIST of arguments] convention in<br></blockquote><blockquote type="cite">lots of other places,<br></blockquote><br>Then it's different. But why did CMake choose this hack over<br>supporting list literal arguments properly? ;)<br><br>(It's not a question for you, I know.)<br><br>In general, I don't like mixing data and meta data. I think it will<br>be really confusing when some of the arguments happen to be in<br>UPPER_CASE (e.g. AST).<br></div></blockquote><div><br></div>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.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div></body></html>