[Greg Banks]
> There are other ways to use "if" statements not covered by these two
> cases, for example a couple of minutes of manual scanning reveals...
> 
> int  '  default tagged command queue depth' CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS 8
> if [ "$CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS" = "0" ]; then
>    bool '  not allow targets to disconnect' CONFIG_SCSI_NCR53C8XX_NO_DISCONNECT
> fi

I would add a guard bool 'Use TCQ' and put the questions under an
if/else.  When you brought this point up before, I grepped and only
found two such instances (where a non-{bool,tristate} was used in an
'if' statement).  Feel free to argue the point, but right now I don't
think two instances is enough to justify changing the compare
operation from "logical tristate" compare to string compare.

> if [ "$CONFIG_IA64_HP_SIM" = "n" ]; then
>   define_bool CONFIG_ACPI y
>   define_bool CONFIG_ACPI_EFI y
>   define_bool CONFIG_ACPI_INTERPRETER y
>   define_bool CONFIG_ACPI_KERNEL_CONFIG y
> fi

CONFIG_IA64_HP_SIM is a bool (actually a choice in a 'choice', but
same result), as opposed to a tristate.  Therefore, since we don't
have to worry about the 'm == !m' weirdness, the block can be
translated pretty much literally:

  dep_if !CONFIG_IA64_HP_SIM
    define_bool CONFIG_ACPI y
    define_bool CONFIG_ACPI_EFI y
    define_bool CONFIG_ACPI_INTERPRETER y
    define_bool CONFIG_ACPI_KERNEL_CONFIG y
  dep_fi

> bool 'Support for hot-pluggable devices' CONFIG_HOTPLUG
> if [ "$CONFIG_HOTPLUG" = "y" ]; then
>    source drivers/pcmcia/Config.in
> else
>    define_bool CONFIG_PCMCIA n
> fi

This one is easy too:

  bool 'Support for hot-pluggable devices' CONFIG_HOTPLUG
  dep_if CONFIG_HOTPLUG
     source drivers/pcmcia/Config.in
  dep_else
     define_bool CONFIG_PCMCIA n
  dep_fi

It doesn't work currently, because my version of Menuconfig doesn't
suppress sub-menus.  But that's a mere implementation bug, the one
such bug I'm still thinking about how to fix.

> > Heh.  No, a flag day is where BIGNUM things have to be patched at
> > once because there's no migration path.  In this case there *is* a
> > migration path, so the only things that break on The Day are
> > things the gcml2 checker (and a grep through the makefiles for
> > suspicious things like 'ifdef') has warned us about but we didn't
> > bother to fix.
> 
> Ok, so not "The Day" but "The Several Weeks During Which Things
> Mostly Still Work".

Assuming everyone uses only dep_* (no 'if [ ]') and does not use '$'
in their dep lines anymore, who actually still cares about symbol
visibility?  Makefiles don't.  C code doesn't.  I think the only case
that still cares is oldconfig, which uses the '# FOO is not set' to
determine that the user has in fact already seen FOO.  However, if FOO
is rendered invisible by its dependencies, then the user has not in
fact seen FOO, and oldconfig won't have to see it either.

Of course, in today's world, 'if [ ]' and dep_* (with those $'s) both
care about the difference between 'n' and ''.  According to my Grand
Plan, not coincidentally, both cases will eventually go away.

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

Reply via email to