From: Peter Korsgaard <jacmet@uclibc.org>
To: buildroot@busybox.net
Subject: [Buildroot] [git commit master] buildroot; move defconfigs to configs/ and print in help
Date: Sun, 22 Nov 2009 22:05:09 +0100 [thread overview]
Message-ID: <87pr7afeyi.fsf@macbook.be.48ers.dk> (raw)
In-Reply-To: <20091111150359.579df608@surf> (Thomas Petazzoni's message of "Wed\, 11 Nov 2009 15\:03\:59 +0100")
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Thomas> Hello,
Thomas> Coming back on this old topic, because I really don't like the
Thomas> new way.
I'm sorry to hear. I do kind of like it ;)
>> True - This change makes it slightly harder for developers, but easier
>> for users to find (and for us to do a test build of all defconfigs
>> prior to release).
Thomas> For developers, it's a mess. You have to explain to developers that
Thomas> they have to put some stuff in this directory, some other stuff into
Thomas> this directory. (BTW the documentation at
Thomas> http://buildroot.org/buildroot.html#board_support hasn't been updated
Thomas> accordingly).
It hasn't? I did update it, and it imho is pretty clear:
You can furthermore create one or more preconfigured configuration
files, referencing those files. These config files are named
something_defconfig and are stored in the toplevel configs/
directory. Your users will then be able to run make something_defconfig
and get the right configuration for your project
Do you have a suggestion for a clearer wording?
I don't see the different directory as a big problem (E.G. it doesn't
seem to be an issue for other projects doing the same, like the Linux
kernel or U-Boot). If people add packages and/or patches for their
custom stuff (I know people at the company I work for do this) they'll
need to look outside their target/device/company/board dir anyway.
Similary, I don't believe name clashes in configs/ are a big problem
(like in Linux/U-Boot).
Thomas> Moreover, it breaks the idea of having out-of-tree board support.
Thomas> Before this change, it was relatively easy since the stuff needed to
Thomas> support one board was centralized in one directory (see my proposal at
Thomas> http://git.buildroot.net/~tpetazzoni/git/buildroot/commit/?id=ed47f42a598c665bf42c4e797187f233b955e285).
Did you rebase? The link doesn't seem to work any more :/
Thomas> To make them more visible to users, I suggest to reorganize
Thomas> target/. All board-stuff should be moved to a top-level boards/
Thomas> directory. This directory would have roughly the same
Thomas> architecture as the current target/device/ directory.
I agree, but that's imho not directly related to where to put
_defconfigs.
Thomas> And then, to make the defconfig files visible to users, just show them
Thomas> in "make help".
With a find-all-files-ending-in-_defconfig-under-here thing? Could be
done, but is kind of ugly - Same for make <foo>_defconfig.
>> The stuff in target/device/ tends to get stale over time, so a bit
>> more visibility is imho good.
Thomas> Let's move it to boards/ then.
Optimist! ;) I don't think that will significantly change the staleness
of it though.
Thomas> True, I forgot to send my comments at that time. Or maybe didn't
Thomas> realized what the impact of the change would be.
Thomas> Is it possible to re-discuss this topic before the 2008.11 release ?
Yes, but I'm about to put out -rc1, so we have limited time.
--
Bye, Peter Korsgaard
next prev parent reply other threads:[~2009-11-22 21:05 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-04 20:20 [Buildroot] [git commit master] buildroot; move defconfigs to configs/ and print in help Peter Korsgaard
2009-10-05 6:48 ` Thomas Petazzoni
2009-10-05 7:09 ` Peter Korsgaard
2009-11-11 14:03 ` Thomas Petazzoni
2009-11-11 18:36 ` Thiago A. Corrêa
2009-11-22 21:05 ` Peter Korsgaard [this message]
2009-11-25 22:02 ` Thomas Petazzoni
2009-11-25 22:16 ` Peter Korsgaard
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=87pr7afeyi.fsf@macbook.be.48ers.dk \
--to=jacmet@uclibc.org \
--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.