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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.