[coreboot] buildrom bug
jordan.crouse at amd.com
Fri Apr 25 20:11:31 CEST 2008
On 25/04/08 12:01 -0600, Myles Watson wrote:
> > On 25/04/08 11:45 -0600, Myles Watson wrote:
> > > > Here's the updated patch. It needs to be preceded by
> > > > svn mv packages/utils packages/nrv2b
> > >
> > > Sorry. Here's the new patch.
> > So here is the million dollar question. If all the .mk
> > files are packages/<package>/<package>.mk, is there anything
> > stopping us from constructing PAYLOAD_AND_DEP_MK like so:
> > PAYLOAD_AND_DEP_MK = $(patsubst %,$(PACKAGE_DIR)/packages/%/%.mk,
> > $(DEPENDS-y) $(PAYLOAD-y) $(HOSTTOOLS-y))
> Doesn't that put you back where you were with the "You need ruby to compile
> grub2"? The point of the PAYLOAD_AND_DEP_MK variable was supposed to be
> that it got set (purposefully) in the config/payloads/<payload>.conf file.
> I think it's reasonable to ask a developer to set the variable when he adds
> the .conf file for a new package.
DEPENDS-y PAYLOAD-y and HOSTTOOLS-y are the dependencies
for what you are actually building.
Our original problem was that we were doing a $(wildcard */*/.mk), which
was including the kitchen sink. So unless your package is somehow listing
grub2 as one of its dependencies, then packages/grub2/grub2.mk won't make
it into the list, and you won't have a problem.
I think it is pretty unreasonable to ask the developer to add the
variable - it includes magic that he shouldn't have to think about,
namely how packages are referenced and included.
And lets look at it this way - 99.99% of the time, its going to be
packages/<package>/<package>.mk - we're just automating the process.
If we want, we can make PAYLOAD_AND_DEP_MK ?= so that the developer
can override it if they want, but I think most people won't want to.
Systems Software Development Engineer
Advanced Micro Devices, Inc.
More information about the coreboot