All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v3 0/16] Provide a mechanism to avoid using #ifdef everywhere
Date: Tue, 14 May 2013 18:15:20 -0400	[thread overview]
Message-ID: <20130514221520.GS29196@bill-the-cat> (raw)
In-Reply-To: <CAPnjgZ3=gZE9vGdJ=6rcr0tC1tnW9_pwqDgzW9gZ+aL0-_Srbw@mail.gmail.com>

On Tue, May 14, 2013 at 02:27:32PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Tue, May 14, 2013 at 2:21 PM, Tom Rini <trini@ti.com> wrote:
> > On Mon, May 13, 2013 at 03:12:07PM -0700, Simon Glass wrote:
> >> Hi Tom,
> >>
> >> On Thu, Mar 21, 2013 at 7:38 AM, Tom Rini <trini@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.
> >
> > I think a lot of our #ifdefery is a problem of code that's in need of
> > some love and re-org and cleaning and updating.  One of the old style
> > rules I still try and follow is that after a few levels of indent code
> > doesn't read well.  Also big nested #ifdefs don't read well.  So we're
> > trading one in for the other.  But your series showed a lot of places
> > where we can re-factor things to improve readability.  So lets go that
> > way.  Then we can see if there's still things to improve on, and what
> > dead code we still have around.
> 
> So are you saying that you are keen on the autoconf idea?

I'm saying lets clean up the code and see if we still need something
like autoconf.  It seems to provide the most benefit in terms of
readability in places that could read a lot better with some clean up
and refactoring before we add new tools to the pile.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130514/11e50ace/attachment.pgp>

  reply	other threads:[~2013-05-14 22:15 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-26 16:10 [U-Boot] [PATCH v3 0/16] Provide a mechanism to avoid using #ifdef everywhere Simon Glass
2013-02-26 16:10 ` [U-Boot] [PATCH v3 01/16] Implement autoconf header file Simon Glass
2013-02-26 16:10 ` [U-Boot] [PATCH v3 02/16] at91: Correct CONFIG_AUTOBOOT_PROMPT definition for pm9263 Simon Glass
2013-02-26 16:10 ` [U-Boot] [PATCH v3 03/16] net: Add prototype for update_tftp, and use autoconf Simon Glass
2013-03-20 19:40   ` Tom Rini
2013-03-20 19:57     ` Simon Glass
2013-03-20 20:30       ` Tom Rini
2013-03-21  1:47         ` Simon Glass
2013-02-26 16:10 ` [U-Boot] [PATCH v3 04/16] main: Separate out the two abortboot() functions Simon Glass
2013-02-26 16:10 ` [U-Boot] [PATCH v3 05/16] main: Move boot_delay code into its own function Simon Glass
2013-02-26 16:10 ` [U-Boot] [PATCH v3 06/16] main: Use autoconf for boot retry feature Simon Glass
2013-02-26 16:11 ` [U-Boot] [PATCH v3 07/16] main: Remove CONFIG #ifdefs from the abortboot() code Simon Glass
2013-02-26 16:11 ` [U-Boot] [PATCH v3 08/16] main: Use get/setenv_ulong() Simon Glass
2013-02-26 16:11 ` [U-Boot] [PATCH v3 09/16] main: Use autoconf for boot_delay code Simon Glass
2013-02-27  9:14   ` Joe Hershberger
2013-02-26 16:11 ` [U-Boot] [PATCH v3 10/16] main: Use autoconf for parser selection Simon Glass
2013-02-26 16:11 ` [U-Boot] [PATCH v3 11/16] main: Fix typos and checkpatch warnings in command line reading Simon Glass
2013-02-27  9:25   ` Joe Hershberger
2013-02-26 16:11 ` [U-Boot] [PATCH v3 12/16] main: Use autoconf " Simon Glass
2013-02-27  9:17   ` Joe Hershberger
2013-02-26 16:11 ` [U-Boot] [PATCH v3 13/16] main: Use autoconf in main_loop() Simon Glass
2013-02-27  9:23   ` Joe Hershberger
2013-02-26 16:11 ` [U-Boot] [PATCH v3 14/16] main: Correct header order Simon Glass
2013-02-26 16:11 ` [U-Boot] [PATCH v3 15/16] main: Add debug_parser() to avoid #ifdefs Simon Glass
2013-02-26 16:11 ` [U-Boot] [PATCH v3 16/16] main: Add debug_bootkeys " Simon Glass
2013-03-21 14:38 ` [U-Boot] [PATCH v3 0/16] Provide a mechanism to avoid using #ifdef everywhere Tom Rini
2013-05-13 22:12   ` Simon Glass
2013-05-14 21:21     ` Tom Rini
2013-05-14 21:27       ` Simon Glass
2013-05-14 22:15         ` Tom Rini [this message]
2013-05-14 22:22           ` Vadim Bendebury
2013-05-14 22:28             ` Tom Rini
2013-05-15 14:13               ` Simon Glass
2013-05-16 16:26                 ` Tom Rini
2013-05-16 18:49                   ` Simon Glass
2013-05-30 13:57                     ` Simon Glass
2013-05-30 15:17                       ` Tom Rini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130514221520.GS29196@bill-the-cat \
    --to=trini@ti.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.