2.4.6p6: dep_{bool,tristate} $CONFIG_ARCH_xxx bugs
Does anyone know if there is any code that would break if
we put quotation marks around the $CONFIG_xxxx references in the dep_xxx commands in all of the Config.in files? In other words, change all commands of the form
dep_tristate CONFIG_FOO 'Foo on x86/pci machines' $CONFIG_PCI $CONFIG_X86
to
dep_tristate CONFIG_FOO 'Foo on x86/pci machines' "$CONFIG_PCI" "$CONFIG_X86"
Then, we could change dep_{bool,tristate} to only treat "" as "n",
in its dependency parameters without effecting how undefined variables are treated elsewhere. For example, CONFIG_FOO being undefined would still cause "make oldconfig" to treat it as "NEW" and ask the user about it.
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104 [email protected] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
Quoted 3 lines · Adam J. Richter
Does anyone know if there is any code that would break if
we put quotation marks around the $CONFIG_xxxx references in thedep_xxxcommands in all of the Config.in files?
That has the same problem that AC was worried about. Variables that used to be treated as "undefined, don't care" are now treated as "undefined, assume n and forbid".
As long as there is any ambiguity about how a rule is meant to treat undefined variables, treating all undefined variables as 'n' is not safe. Before making a global change like this, first verify that no rule treats undefined variables as "don't care". Otherwise something will break.
Hi Keith, Adam.
Quoted 7 lines
Quoted 3 lines
Does anyone know if there is any code that would break if we put quotation marks around the $CONFIG_xxxx references in the
dep_xxxcommands in all of the Config.in files?That has the same problem that AC was worried about. Variables that used to be treated as "undefined, don't care" are now treated as "undefined, assume n and forbid".
Whilst there could easily be problems if we allow that for any of the variables, it can't be a problem if we restrict it to variables specifying the architecture in question, as per my previous email.
Quoted 5 lines
As long as there is any ambiguity about how a rule is meant to treat undefined variables, treating all undefined variables as 'n' is not safe. Before making a global change like this, first verify that no rule treats undefined variables as "don't care". Otherwise something will break.
Agreed.
Best wishes from Riley.