[Buildroot] Sample configurations / test suite ?
jacmet at uclibc.org
Mon Jul 1 10:03:17 UTC 2013
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni at free-electrons.com> writes:
>> For both use cases, it makes the most sense if these defconfigs are
>> part of the buildroot tree.
Thomas> In order to keep those configurations consistent with the rest of
Thomas> Buildroot, I agree that having them in the Buildroot tree is probably
Thomas> the easiest option. However, I'm worried about the size of it: I was
Thomas> not only thinking of defconfigs, but potentially additional artifacts
Thomas> needed to make the build work.
Yes, I also think they need to be in tree to really be useful.
>> The risk is that the configs/ directory becomes too large and unwieldy
>> (people will have to browse it to find the defconfig they want). So
>> perhaps this calls for changing it into a tree.y
>> Personally, I think it makes sense to move the defconfigs into the
>> board/ directory. Many defconfigs already refer into there for kernel
>> configs or specific patches, so it makes sense to put the defconfig in
>> the same place.
Thomas> Funnily enough, the defconfigs *used* to be in the board/ directory
Thomas> (which at the time was target/device). We had a discussion back in the
Thomas> days on whether the defconfigs should remain with their board, or
Thomas> grouped in the top-level configs/ directory.
Thomas> and my complaint
Gah, 2009 ;)
I do still think having the available configs listed together (like
linux/barebox arch/$ARCH/configs, or u-boot's boards.cfg) is nice for
Thomas> That said, after several years, I feel that configs/ was a pretty good
Thomas> choice, I don't really feel the need of moving things back to board/,
Thomas> especially considering the change it will cause to all users.
Thomas> Moreover, I am not sure that those test suite / demos
Thomas> configurations should be located in the same place as the minimal
Thomas> defconfigs we have in configs/.
>> And while I'm on this subject, I think the structure of the board
>> directory is not very clear. It would make sense to me to switch to the
>> layout that U-Boot uses: board/<arch>/<soc>/<boardname>/ (although the
>> <soc> level may be optional for us). You can expect people to know what
>> the basic architecture of the processor is, but not always who the vendor
>> is (which is probably why raspberrypi, beaglebone and gnublin don't have
>> a vendor directory). Or sometimes there are multiple vendors for the same
>> board (e.g. Beagleboard and SabreLite).
U-boot actually nowadays normally use board/<vendor>/<boardname>, which
is in line with what we do.
Bye, Peter Korsgaard
More information about the buildroot