[U-Boot] [PATCH v3 0/16] Provide a mechanism to avoid using #ifdef everywhere

[Simon Glass]

Hi Tom,

On Thu, Mar 21, 2013 at 7:38 AM, Tom Rini <trini at ti.com> wrote:
> On Tue, Feb 26, 2013 at 08:10:53AM -0800, Simon Glass wrote:
>
>> Many parts of the U-Boot code base are sprinkled with #ifdefs. This makes
>> different boards compile different versions of the source code, meaning
>> that we must build all boards to check for failures. It is easy to misspell
>> an #ifdef and there is not as much checking of this by the compiler. Multiple
>> dependent #ifdefs are harder to do than with if..then..else. Variable
>> declarations must be #idefed as well as the code that uses them, often much
>> later in the file/function. #ifdef indents don't match code indents and
>> have their own separate indent feature. Overall, excessive use of #idef
>> hurts readability and makes the code harder to modify and refactor. For
>> people coming newly into the code base, #ifdefs can be a big barrier.
>>
>> The use of #ifdef in U-Boot has possibly got a little out of hand. In an
>> attempt to turn the tide, this series includes a patch which provides a way
>> to make CONFIG macros available to C code without using the preprocessor.
>> This makes it possible to use standard C conditional features such as
>> if/then instead of #ifdef. A README update exhorts compliance.
>
> OK, this is true.  Looking over the series, a number of the patches are
> just general fixes / improvements that don't depend on the autoconf_...
> work.  Lets split this out now and take them in now as they seem like
> reviewable by inspection code.

Well sorry I didn't make time to get this done last time. I can do
this now or...

>
> For the approach itself, I'm not sure which is best here.  In a lot of
> cases we're trading an #ifdef for adding a level of indent to already
> pretty indented code and that feels like a wash, in terms of readability
> to me.  We probably need to re-factor some of the code in question there
> too for readability, then see about using autoconf_... type things, or
> maybe something else.

I think you are saying to do the rearrangement and clean-up first,
then add autoconf afterwards. I can do that but really I am wondering
what you think of the autoconf concept? The Kconfig stuff is related
here too, but first I would like to decide on what to do with the
#ifdefs.

Regards,
Simon

>
> --
> Tom