Kai Germaschewski wrote:
>
> On Thu, 15 Aug 2002, Peter Samuelson wrote:
>
> > The more I think about it, the more I think the default if_dep should
> > do the m-restricting thing. That way:
> >
> > dep_bool FOO1 BAR BAZ
> > dep_mbool FOO2 BAR BAZ
> > dep_tristate FOO3 BAR BAZ
> >
> > is exactly equivalent to
> >
> > if_dep BAR BAZ
> > bool FOO1
> > mbool FOO2
> > tristate FOO3
> > fi_dep
>
> > Of course, that requires the invention of 'mbool'. But I do believe
> > it covers most if not all common cases. I guess in this case, though,
> > it's still an open question whether 'define_bool' should be immune
> > from the M effect (like 'mbool') or not.
>
> Seeing it from that point of view, it may actually turn into something
> which can agree with much more easily.
>
> Maybe it actually suffices to declare if_dep, fi_dep as "virtually adds
> the listed arguments to each statement in the enclosed region". Maybe
> there would be a better name for that, then if_dep, OTOH using if_dep
> makes it quite clear what else_dep does.
Ok, we need to be a little bit careful about semantics here, or there is
going to be issues converting the existing corpus.
Currently the "if" syntax and dependencies are not the same thing; the
"if" condition is purely a visibility limit, and deps are both value and
visibility limits. This means that
if [ "$CONFIG_FOO" = "y" ]; then
bool '...' CONFIG_BAR
fi
is not semantically identical to
dep_bool '...' CONFIG_BAR $CONFIG_FOO
(even ignoring the "" issue) because in the second case CONFIG_FOO=n
forces CONFIG_BAR=n whereas in the first case it makes no difference
to the value of CONFIG_BAR, so CONFIG_BAR will retain the value from
previous definitions or defconfig.
The proposed "if_dep" (or "dep_if") acts as both a visibility and a
value limit. So
if_dep CONFIG_BAZ
bool '...' CONFIG_QUUX
fi_dep
is semantically equivalent to
if [ "$CONFIG_BAZ" = "y" -o "$CONFIG_BAZ" = "m" ]; then
dep_mbool '...' CONFIG_QUUX $CONFIG_BAZ
else
define_bool CONFIG_QUUX n
fi
There's nothing wrong with this, in fact it's probably a very handy
construct. But it's not a new syntax for "if", it's a totally new
construct with new semantics. Furthermore, you're proposing changes to
the existing behaviour of existing statements like "bool". In fact, at
this point you're talking about changing the language in possibly
incompatible ways, not just extending it to regularise semantics.
I think we should focus more on first fixing problems with the existing
corpus which can be fixed without changing syntax, then starting to
think about language redesign for the 2.7 timeframe.
> [...]I didn't look into like choice statements, but I'd
> hope it's possible to add dependencies to them, too, for consistency.
Adding a tristate value limit to "int" or "hex" makes no sense, nor
to "choice". You'd have to define the semantics as "if_dep affects the
visibility of all statements and the values of bools and tristates only".
> OTOH, one of the problems I can see already is that
>
> bool '...' CONFIG_FOO
> if [ "$CONFIG_FOO" = "y" ]; then
> bool '...' CONFIG_BAR
> [...]
> else
> define_bool CONFIG_BAR y
> fi
>
> doesn't translate well.
Or all the cases where there are further "if"s inside the "else".
>
> (Hacks I can see would be:
>
> bool '...' CONFIG_FOO
> if_dep CONFIG_FOO
> bool 'not ...' CONFIG_NOT_BAR
> [...]
> fi_dep
> define_bool CONFIG_BAR !CONFIG_NOT_BAR
Blech.
> bool '...' CONFIG_FOO
> if_dep CONFIG_FOO
> bool '...' CONFIG_FOO_BAR
> [...]
> fi_dep
> define_bool CONFIG_BAR CONFIG_FOO_BAR or !CONFIG_FOO
I think a better solution would be to provide separate "if"like statements,
one which is a pure visibility limit like the old "if" but with the
syntax cleaner and the behaviour with "" regularised; the other which
does both visibility limit and a value limit on "dep_bool"s & "dep_tristate"s
(but those only, the existing "bool" & "tristate" remain unchanged).
If you look at the CML2 rulebase you will see constructs equivalent to both
of these in use.
Greg.
--
the price of civilisation today is a courageous willingness to prevail,
with force, if necessary, against whatever vicious and uncomprehending
enemies try to strike it down. - Roger Sandall, The Age, 28Sep2001.
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
