"Eric S. Raymond" wrote:
> There is a third possibility. autoconfigure.sh is going to pass its
> results to cmlconfigure.py in a file with the format of a config.out.
> Right now all those results are symbol bindings (FOO=y, BAR=n).
> Conceivably autoconfigure.sh could also pass a directive like
> "finished PCI" which would tell cmlconfigure.py that all PCI-dependent
> symbols not yet set should be set to `n'.
>
> Either of these alternatives (autoconfigure.sh querying the rulebase
> or passing a directive to cmlconfigure.py) could work nicely. Which
> is the right thing is really a question of design philosophy -- that
> is, what do we *want* the roles of autoconfigure.sh and
> cmlconfigure.py to be? And how closely coupled should they be?
I already thinked two possibilities (there are similar to your
alternatives).
1) From CML2 rules I derive all symbols that depends on some rules.
The new tables are included in autoconfigure.sh
This can be done in Makefile, so the symbols are always updated,
and the autoconfigure is still simple shell, so it can be run
to the TARGET machine.
(easy ? python script).
2) I give CML2 some rules, and set the symbols (not already set)
according to these rules.
(complex hack in CML2 ?)
These rules IMHO can be more complex.
I.e. I think that for PCI I should use the
"if PCI and not PCI_HOTPLUG then set no".
Then CML2 should ask user if he want HOTPLUG support, and then
eventually the PCI_HOTPLUG card. (I should detect the PCI_HOTPLUG,
but yet is a edge feature, so I know little about this, but anyway
it is a simple example).
For the syntax of autoconfig.out, I think it better to hide
such rules in meta-commens (e.g. #:RULES ...)
I have no preferences.
giacomo
_______________________________________________
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
