[Greg Banks]
> Ok, we need to be a little bit careful about semantics here, or
> there is going to be issues converting the existing corpus.
Agreed.
> 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.
Good point. I considered that point and I think I have it covered in
my current patch (which still doesn't work - I was gone all weekend
and got nothing done), but I guess the *documentation* doesn't
specify.
> 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.
My current implementation of if_dep is *not*, as previously theorised,
a drop-in two-way replacement for adding dependencies to the end of
dep_* statements. I currently have it short-circuiting, so statements
are in effect *not* executing in the 'n' case (or the 'm' case, for
bool / dep_bool).
In other words, my implementation matches current 'if [ ]' behavior,
and this was on purpose. I suppose this should be made clearer in the
documentation.
> 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
No, at least not in my implementation. Like I said, my docs might be
unclear on this point.
> 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.
Agreed.
> 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".
That's the plan, yes.
> 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).
I think that is overengineering. If you really don't want value
limits, you use 'if_dep !CONFIG_FOO=n' which, in the case of
CONFIG_FOO={y,m}, does not restrict the block.
(This works because I currently specify that the = operator treats ''
as 'n'. I suppose this "feature" is worth debating, but I think it is
useful.)
Peter
-------------------------------------------------------
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
