[U-Boot] [PATCH 05/11] mtd: Build nand_util.o for CONFIG_ENV_IS_IN_NAND in SPL

[Scott Wood]

On Thu, 2013-09-26 at 16:45 -0400, Tom Rini wrote:
> On 09/26/2013 04:42 PM, Scott Wood wrote:
> > On Thu, 2013-09-26 at 16:28 -0400, Tom Rini wrote:
> >> Cc: Scott Wood <scottwood at freescale.com>
> >> Signed-off-by: Tom Rini <trini at ti.com>
> >> ---
> >>  drivers/mtd/nand/Makefile |    1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
> >> index 366dee6..bb5b29d 100644
> >> --- a/drivers/mtd/nand/Makefile
> >> +++ b/drivers/mtd/nand/Makefile
> >> @@ -24,6 +24,7 @@ COBJS-$(CONFIG_SPL_NAND_LOAD) += nand_spl_load.o
> >>  COBJS-$(CONFIG_SPL_NAND_ECC) += nand_ecc.o
> >>  COBJS-$(CONFIG_SPL_NAND_BASE) += nand_base.o
> >>  COBJS-$(CONFIG_SPL_NAND_INIT) += nand.o
> >> +COBJS-$(CONFIG_ENV_IS_IN_NAND) += nand_util.o
> > 
> > Not all NAND SPLs will want this.  Define a new CONFIG_SPL_* symbol, or
> > perhaps it could just use CONFIG_SPL_NAND_BASE.
> 
> Then they won't get it.  Without CONFIG_SPL_ENV_SUPPORT that all gets
> discarded. 

Anonymous strings won't.

> And talked about before adding CONFIG_SPL_ENV_... and I
> didn't want to go down that path.  If you feel strongly about not
> building the object we can guard this with CONFIG_SPL_ENV_SUPPORT checks
> perhaps?

And then we get a bigger mess if something wants nand_util for some
other reason...

I think the entire way SPL has been structured is a mistake, and it
should have been viewed as just multiple U-Boot configs that happen to
be automatically built and concatenated together under one user-visible
target name.  Then, if existing config mechanisms are not fine grained
enough, make them finer grained.  Bring in kconfig to sort out the
dependency mess.

-Scott