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

[Simon Glass]

Hi Albert,

On Thu, Jun 27, 2013 at 12:04 AM, Albert ARIBAUD
<albert.u.boot at aribaud.net>wrote:

> Hi Simon,
>
> On Mon, 24 Jun 2013 17:52:03 -0700, Simon Glass <sjg at chromium.org>
> wrote:
>
> > Hi Albert,
> >
> > On Sun, Jun 23, 2013 at 12:29 AM, Albert ARIBAUD
> > <albert.u.boot at aribaud.net>wrote:
> >
> > > Hi Simon,
> > >
> > > On Mon, 17 Jun 2013 07:44:52 -0700, Simon Glass <sjg at chromium.org>
> > > wrote:
> > >
> > > > Note that a config_drop.h file is added - this defines all the
> CONFIGs
> > > > which are not used in any board config file. Without this, autoconf
> > > cannot
> > > > define the macros for this CONFIGs.
> > > >
> > > > Compile time for main.c does not seem to be any different in my
> tests.
> > > The
> > > > time to perform the 'dep' step (which now creates autoconf.h)
> increases,
> > > > from about 2.8s to about 4.6s. This additional time is used to grep,
> sed
> > > > and sort the contents of all the header file in U-Boot. The time for
> an
> > > > incremental build is not affected.
> > > >
> > > > It would be much more efficient to maintain a list of all available
> > > CONFIG
> > > > defines, but no such list exists at present.
> > >
> > > Stop me if I am wrong, but do you not have this list already, since at
> > > one point you grep, sed and sort the whole list of config options, then
> > > at another point generate the list of unused ones?
> > >
> >
> > Well yes I create the list. But I don't 'have' it in the sense that it
> is a
> > pre-existing file in the tree. My point was that if the file existed I
> > would not need to create it in the build system. I asked about this at
> one
> > point, and the comment was made that putting it in the source tree
> > 'staticly' is risky, since someone might add a new option and it would
> not
> > work.
> >
> > Perhaps when Kconfig is in there things will be different.
>
> Understod.
>
> > > Granted, that's the list of config options defined, not necessarily the
> > > list of options used, but a second variation of the grep/sed/sort might
> > > give you a hint on that.
> > >
> > > Plus, I would love having scripts in tools/ that look for either
> > > defined or used config options.
> > >
> >
> > With this series you kind-of get this feature - you can look at the files
> > it creates along the way.
>
> What I meant is, this patch creates those lists with scripts. I'd like
> these scripts to be available to the developer in tools/ so that anyone
> can regenerate the lists (and do this only) at any time.
>

Yes, I figured that's what you were angling for. I will take a look.

Regards,
Simon