[Buildroot] [PATCH 1/6] Remove the "project" feature
Peter Korsgaard
jacmet at uclibc.org
Sat Sep 19 15:26:29 UTC 2009
>>>>> "Bernhard" == Bernhard Reutner-Fischer <rep.dot.nop at gmail.com> writes:
Hi,
Bernhard> On Wed, Sep 16, 2009 at 11:07:41PM +0200, Thomas Petazzoni wrote:
>> flush:
>> - rm -f $(PROJECT_BUILD_DIR)/tgt-config.cache
>> + rm -f $(BUILD_DIR)/tgt-config.cache
>>
>> %_defconfig: $(CONFIG)/conf
>> cp $(shell find ./target/ -name $@) .config
>> -@$(MAKE) oldconfig
Bernhard> That find is gross. $(wildcard $(TOPDIR)/target/*/$(@)_defconfig)
Bernhard> and we have $(Q) that is either set to '@' or is empty.
Bernhard> Apart from that a failing oldconfig is and should be fatal.
Yes - Notice that it's not something new Thomas is introducing, it has
been in the tree for a long time (Ulf afaik added it).
I think I would actually prefer having all defconfigs together in
something like configs/ just like the Linux kernel has it instead of
spread over the tree. That has a number of advantages:
- %_defconfig rule gets a lot simpler - E.G. something like:
%_defconfig: $(TOPDIR)/config/%_defconfig:
cp $^ $(TOPDIR)/.config
- We could display the available defconfigs in make help:
@$(foreach b, $(notdir $(wildcard $(TOPDIR)/configs/*_defconfig)), \
printf " %-22s - Build for %s\\n" $(b) $(subst _defconfig,,$(b));)
- It's easy to build all defconfigs before a release with simple shell
scripting, and it's easy for newcomers to see what configs are
available
The disadvantage is that the defconfig isn't together with the other
target/device/* files.
I implemented something like that for the company I work for, but Ulf
added the current implementation before I got mine committed.
Comments, anyone?
--
Bye, Peter Korsgaard
More information about the buildroot
mailing list