Bug in user-guide or [cook] function

[Meikel Brandmeyer]

Hello,

the [cook] function returns the arguments, which were brought up to
date. Contrary to the user-guide, which states the fucntions returns
"true" if all files are now up to date or "false" if they could not be
built (I read that as "at least one could not be built").

This explains the behaviour Felix Klose reported in September [1].
Depending on the kind of the first argument, the context of the
function call and the PATH settings.

On global level or recipe level, cook would try to execute the first
element of return value of [cook] as a command with the rest of the
return values as arguments. If the first argument is no binary, this
will obviously fail. If it is a binary, what happens depends on the
PATH setting. If the binary is not in the PATH, the execute will fail.
If the binary is found in the PATH it is executed with more or less
unpredictable effects (depending of the [cook] arguments, etc.).

One more caveat for [cook]: (only documented in the [cook] test...)
----8<----
if [not [cook foo]] then
	fail;

#include foo
----8<----

This does also not work as expected, since the parser looks for a
possible else and tries to include foo, which does not work if foo does
not exist. One needs either an empty else-branch or a simple semicolon
between the #include and the if.

This is actually something one should always do where ever an #include
immediately follows an if. The first word in the included file could be
an else giving lots of funny effects. (If you don't expect them...)

Sincerely
Meikel

[1]:
http://www.auug.org.au/pipermail/cook-users/2007-September/000343.html

-- 
http://kotka.de