> The _real_ problem is preprocessor abuse. BTW, could we schedule for
> 2.5 the following?
> * things like CONFIG_FOO are _always_ defined. As 0 or 1, that is.
> * #ifdef CONFIG_FOO => if (CONFIG_FOO) in *.c. gcc will kill the unused
> branches just fine.
Notwithstanding the string literal gcc bug already mentioned....
It's non-trivial at the kernel config stage. As in, a rewrite of
config and menuconfig (might be easier for xconfig). Because currently
they leverage bash parsing and control flow, so parts of Config.in
files are not seen by Configure/Menuconfig proper. So some of the
#define CONFIG_X 0 can't happen, with current design.
It's really the same problem you're complaining about, all over again.
bash acts as the preprocessor here. Not that most of us particularly
like the bash-parsing implementations currently in use, but there they
are. If and when esr's new config stuff is adopted this sort of thing
will be *much* easier to add cleanly.
Actually, hackery would be possible -- have a stage of `make config'
that basically greps all Config.in files for words CONFIG_* and makes
sure they are all #defined, one way or another. Hackery is hackery,
though there's already a lot of it in the kbuild system.
1. s/#ifdef/#if/ all over the kernel (for CONFIG_* only of course --
other macros aren't guaranteed to evaluate to true).
2. Play with kbuild until you get the 1's and 0's.
3. Start putting the real C control flow in.
I will do the step 2 hackery, if you want. (As I said it won't be
> * Yes, Virginia, it means that controlflow-affecting expansion has to
> go. Good riddance, IMO.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:29 EST