[CMake] Bug? project(X T) returns weird error

[Brian Davis]

>
> Good idea but this seems difficult to do.
> In Olaf case it may be doable to spit out a better error message
> explicitely
> saying that "T" was considered as the "<language>" argument of PROJECT,
> because PROJECT is a builtin
>
> I was just agreeing with Olaf and stating a issue I ran into on error
reporting when calling/using functions and macros.  I don't have any
solutions for him.  Wish I did.


> In this case the MACRO CMake command has only "positional" arguments
> handling.
> So if you miss-use the ParseArguments macros the better you can do is
> enhance
> the ParseArguments macro in order to do a better job while checking
> its arguments.
>
>
Yes the "positional" argument handling IMO is the problem.   This leads to
scouring code to determine what is wrong.  It was as though the function
that contained the parse arguments call did not exist.  So the error
reported had nothing to do with the real problem.


> May be the only way to have a better error reporting would be to have a new
>
> kwmacro(<name> KEYWORD <kw1> arg1 KEYWORD kw2 arg2 .... KEYWORD  kwN argN)
>
> kwmacro(<name>)
>
> that would support keyword call instead of positional call.
> i.e.
>
>
Named parameters may help, but the problem with the parser not recognizing
(looking ahead for) the trailing paren and inferring missing parameters I
believe is the root failure.  Naming the arguments would aid in readability,
but not fix the CMake parser.  Maybe you are saying implementing named
macros and changing the parser is the solution?

-- 
Brian J. Davis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100722/292a937d/attachment-0001.htm>