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.
Then, there would be some more steps, which could be easily done:
Make every statement accepts dependencies (and depreciate the dep_
prefixes, since they become unnecessary). There really isn't any reason
for the difference between bool and dep_bool right now, it only leads to
confusion and mistakes. I didn't look into like choice statements, but I'd
hope it's possible to add dependencies to them, too, for consistency.
Extend the normal dep_* dependencies (now just called *) to accept the
same kind of dep lines as if_dep, i.e. !, =[ymn], !=[ymn], 'or', 'and'.
Also, when doing that conversion, I think it may be worthwhile to get rid
of the distinction between mbool and bool by something like, changing
dep_mbool 'CAPI2.0 filesystem support' CONFIG_ISDN_CAPI_CAPIFS
$CONFIG_ISDN_CAPI_CAPI20
to
bool 'CAPI2.0 filesystem support' CONFIG_ISDN_CAPI_CAPIFS' CONFIG_ISDN_CAPI!=n
and
dep_bool ' AVM A1 (Fritz)' CONFIG_HISAX_AVM_A1 $CONFIG_ISA
to
bool ' AVM A1 (Fritz)' CONFIG_HISAX_AVM_A1 CONFIG_ISA=y
I think a sensible default would be m -> y in this case (like mbool),
which would allow to handle 95% of the cases with just
bool 'CAPI2.0 filesystem support' CONFIG_ISDN_CAPI_CAPIFS' CONFIG_ISDN_CAPI
bool ' AVM A1 (Fritz)' CONFIG_HISAX_AVM_A1 CONFIG_ISA
(both cases are equivalent to the above, CONFIG_ISA is a bool)
If the real old "dep_bool" is needed, it can be written as "CONFIG_FOO=y",
in most cases "CONFIG_FOO!=n" <=> "CONFIG_FOO" will be what's needed.
I'd be interested to see if these statements are actually sufficient to
express all we've got today. A nice side effect of the above definition of
if_dep would be that
bool '...' CONFIG_FOO
if [ "$CONFIG_FOO" = "y" ]; then
bool '...' CONFIG_BAR
[...]
else
define_bool CONFIG_BAR n
fi
can turn into just
bool '...' CONFIG_FOO
if_dep CONFIG_FOO
bool '...' CONFIG_BAR
[...]
fi_dep
(The CONFIG_FOO=n case would still run through the statements included by
if_dep / fi_dep, automatically setting all vars to 'n', since one of their
deps is 'n')
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.
(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
or
bool '...' CONFIG_FOO
if_dep CONFIG_FOO
bool '...' CONFIG_FOO_BAR
[...]
fi_dep
define_bool CONFIG_BAR CONFIG_FOO_BAR or !CONFIG_FOO
both not particularly nice, but if there's only like one or two cases like
this in the current config.in's, it may be acceptable)
Oh well, I think the only way to find out if all that is really a good
idea is to try, convert some config.in's and look at the result.
--Kai
-------------------------------------------------------
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
