From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] Sample configurations / test suite ?
Date: Tue, 02 Jul 2013 07:56:13 +0200 [thread overview]
Message-ID: <51D26B7D.4020801@mind.be> (raw)
In-Reply-To: <20130701091925.6c67a6c7@skate>
On 07/01/13 09:19, Thomas Petazzoni wrote:
> Dear Arnout Vandecappelle,
>
> On Mon, 01 Jul 2013 08:00:02 +0200, Arnout Vandecappelle wrote:
>
>>> What do you think about this? Do you have ideas on how to implement
>>> this? Should it be part of the Buildroot tree itself, or something
>>> separate? If something separate, how do we keep Buildroot and this
>>> separate tree in sync?
>>
>> For both use cases, it makes the most sense if these defconfigs are
>> part of the buildroot tree.
>
> In order to keep those configurations consistent with the rest of
> Buildroot, I agree that having them in the Buildroot tree is probably
> the easiest option. However, I'm worried about the size of it: I was
> not only thinking of defconfigs, but potentially additional artifacts
> needed to make the build work.
I don't see that becoming an issue, honestly.
When it does, we can still split it up I guess.
>> 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.
>>
>> 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.
>
> Funnily enough, the defconfigs *used* to be in the board/ directory
> (which at the time was target/device). We had a discussion back in the
> days on whether the defconfigs should remain with their board, or
> grouped in the top-level configs/ directory.
>
> See
> http://lists.busybox.net/pipermail/buildroot/2009-October/029556.html
> and my complaint
> http://lists.busybox.net/pipermail/buildroot/2009-October/029559.html.
>
> That said, after several years, I feel that configs/ was a pretty good
> choice, I don't really feel the need of moving things back to board/,
> especially considering the change it will cause to all users.
Can't argue with the wisdom of years :-)
> Moreover, I am not sure that those test suite / demos
> configurations should be located in the same place as the minimal
> defconfigs we have in configs/.
Good point. But then, that goes against the "putting all configs
together" philosophy.
>
>> 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).
>
> Hmm, no strong opinion on this one. How many end users know which SoC
> the RasberryPi is using?
And how many people know who is the vendor of the RPi? :-)
Regards,
Arnout
>
> Best regards,
>
> Thomas
>
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
prev parent reply other threads:[~2013-07-02 5:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-26 22:43 [Buildroot] Sample configurations / test suite ? Thomas Petazzoni
2013-06-28 17:05 ` Yann E. MORIN
2013-07-01 6:00 ` Arnout Vandecappelle
2013-07-01 7:19 ` Thomas Petazzoni
2013-07-01 10:03 ` Peter Korsgaard
2013-07-02 5:56 ` Arnout Vandecappelle [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51D26B7D.4020801@mind.be \
--to=arnout@mind.be \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox