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

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

Hi Simon,

On Mon, 24 Jun 2013 17:52:03 -0700, Simon Glass <sjg@chromium.org>
wrote:

> Hi Albert,
> 
> On Sun, Jun 23, 2013 at 12:29 AM, Albert ARIBAUD
> <albert.u.boot@aribaud.net>wrote:
> 
> > Hi Simon,
> >
> > On Mon, 17 Jun 2013 07:44:52 -0700, Simon Glass <sjg@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.

> Regards,
> Simon

Amicalement,
-- 
Albert.