G'day
[EMAIL PROTECTED] wrote:
>
Thanks for the answers.
> No. I've added this to the Reference:
>
> <para>Normally, a symbol used as a sub-menu guard will be a bool or trit.
> They are also permitted to be numeric,
Ok, I've implemented this.
> As an accident of implementation, strings are also permitted as guards with
> "" being treated as y and everything else as n. But I don't think I want
> anyone to know that :-).
Ok, I've ignored that. My parser spits an error if a subtree guard
is of any type other than bool, trit, dec, or hex.
> > 2. The Reference does not specify the "nohelp" condition.
> >
> > 3. The Reference does not specify the ?: trinary operator,
> > including its syntax and operator precedence.
>
> That's odd. I wonder if your Reference copy is out of date somehow?
> These have been explained in the master for a while -- although you
> did cause me to realize that I hadn't added ?: to the precedence table?
I'm looking at kernel-tree/Documentation/kbuild/cml2-reference.sgml
in cml2-1.2.3.tar.gz. The string "nohelp" is not present anywhere,
nor is "?" "?:" or "trinary". I can't find any mention of ?: in the
BNF nor the precedence table, nor of "nohelp" in the section whose
id="condition-on". OTOH another recent feature, vital trit type for
query symbols, is documented.
If there's a more recent Reference, it's not getting into the tarball.
> > 4. In at least two different places the following happens.
> >
> > derive FOO from n
> > unless FOO suppress BAR BAZ
> >
> > Is the type of FOO (derived by the parser) bool or trit?
>
> Astute question!
The parser found it.
> The derived type is bool.
Ok. I've changed my parser to give literals y,m,n the smallest
type which will hold them, bool for y,n and trit for m. The 1.2.3
corpus parses fine now.
> The reason I have not documented this is that one of the items on
> my to-do list is getting rid of type derivation. The only thing it's
> used for is controlling print formats in config.out.
In my code type derivation is one of the pieces of data used to feed
a whole lot of parsetime and runtime checks. It was a pain to implement
but I think worth it for the extra assurance that the rulebase is free
of avoidable errors.
Greg.
--
These are my opinions not PPIs.
_______________________________________________
kbuild-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/kbuild-devel
