From: Mike Zick <minimod@morethan.org>
To: buildroot@busybox.net
Subject: [Buildroot] Project layout : where to put the .config files
Date: Thu, 30 Jan 2014 08:42:13 -0600 [thread overview]
Message-ID: <20140130084213.2dcae4c9@core2quad.morethan.org> (raw)
In-Reply-To: <780030598.4903299.1391091002877.JavaMail.root@openwide.fr>
On Thu, 30 Jan 2014 15:10:03 +0100 (CET)
Jeremy Rosen <jeremy.rosen@openwide.fr> wrote:
> > I.E: To make Buildroot the central control point for the
> > other components that make up a complete project.
> >
> > Perhaps a: BR_EXTERNAL/sub-tree ?
> > Perhaps a: BR_PROJECT tree ?
> >
> > Keeping in mind that we do not want to upset the world
> > of users that use Buildroot commercially.
> >
>
> yes, but i'm pretty sure most of us would be glad to have a
> "clean way" to do a complete project under buildroot
>
Ah, another point of agreement then.
The current "put them in 'public' tree and move if required"
and the current "put them in the 'private' tree and move if
required" is becoming a bit messy.
So without trying to answer my own questions above -
Start with adding some infra-structure for 'project related'
files; and
Then using that to support the collection of .config files.
That would be of general use to the Buildroot system and
consistent with the "keep it clean, keep it simple" objective.
The end-user could still decide on the 'ship/don't ship' question
by including the 'project related' stuff or not.
It could also help answer the question of: "BR provides hooks
to external scripting - but where do I put them in an organized
manner?"
>
> > For instance:
> > The subject of "are the .config files 'required public' files?"
> > The current set-up leaves that answer to the end user with
> > commands that will include them in the 'public' buildroot tree.
> >
>
> I'm not sure what you mean here... I'm mainly thinking in term
> of project organisation. if the .config is considered derived
> from buildroot then the exact position doesn't matter. I have
> to make it public, and usually in another way than by upstreaming
> since this is a complete project and not a board defconfig...
>
There has already been (years ago) a Buildroot fork from those
that wanted it to become a complete project system.
So just providing the basic organizational infra-structure is
probably a good idea now.
- - - -
Let us pause here for others to comment.
Mike
prev parent reply other threads:[~2014-01-30 14:42 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1357102119.4889305.1391074415327.JavaMail.root@openwide.fr>
2014-01-30 9:53 ` [Buildroot] Project layout : where to put the .config files Jeremy Rosen
2014-01-30 9:59 ` Thomas De Schampheleire
2014-01-30 10:42 ` Jeremy Rosen
2014-01-30 11:00 ` Thomas De Schampheleire
2014-01-30 11:11 ` Sagaert Johan
2014-01-30 11:39 ` Mike Zick
2014-01-30 12:34 ` Jeremy Rosen
2014-01-30 13:54 ` Mike Zick
2014-01-30 14:10 ` Jeremy Rosen
2014-01-30 14:42 ` Mike Zick [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=20140130084213.2dcae4c9@core2quad.morethan.org \
--to=minimod@morethan.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox