From mboxrd@z Thu Jan  1 00:00:00 1970
From: Wolfgang Denk <wd@denx.de>
Date: Fri, 08 Jul 2011 14:37:53 +0200
Subject: [U-Boot] [RFC PATCH 1/4] Adapt config.mk for usage in
	spl/Makefile
In-Reply-To: <4E16ECB6.5070402@ti.com>
References: <1309352967-5719-1-git-send-email-aneesh@ti.com>
	<1309883182-12854-1-git-send-email-daniel.schwierzeck@googlemail.com>
	<1309883182-12854-2-git-send-email-daniel.schwierzeck@googlemail.com>
	<20110708090838.E92A9126F38F@gemini.denx.de>
	<4E16D9DA.4080803@ti.com>
	<20110708111900.24DFF126F38F@gemini.denx.de>
	<4E16ECB6.5070402@ti.com>
Message-ID: <20110708123753.9910D15794A4@gemini.denx.de>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Dear Aneesh V,

In message <4E16ECB6.5070402@ti.com> you wrote:
>
> >> Without CONFIG_NORMAL_UBOOT this becomes a little cumbersome.
> >
> > Hm... instead of
> >
> > COBJS-$(CONFIG_NORMAL_UBOOT) += fileA.o
> >
> > we could use
> >
> > COBJS-$(if $(CONFIG_UBOOT_SPL_BUILD),,y)
> 
> This is what I was trying to avoid. Isn't the above more obvious for
> lay-users of make?

Yes, it is easier, but it doesn't scale.  Today, for you anything that
is not UBOOT_SPL_BUILD, is considered to be "NORMAL".  Tomorrow, we
may have additional features FOO, BAR and BAZ that need the same type
of handling.  So how do you intend to handle this?  Assume a system
that selects UBOOT_SPL_BUILD and FOO, but neither BAR nor BAZ?  Versus
a system that selects FOO and BAZ, but neither UBOOT_SPL_BUILD nor BAR?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A stone was placed at a ford in a river with the inscription:
"When this stone is covered it is dangerous to ford here."