From: Jeremy Rosen <jeremy.rosen@openwide.fr>
To: buildroot@busybox.net
Subject: [Buildroot] Project layout : where to put the .config files
Date: Thu, 30 Jan 2014 10:53:58 +0100 (CET) [thread overview]
Message-ID: <153768653.4890423.1391075638245.JavaMail.root@openwide.fr> (raw)
In-Reply-To: <1357102119.4889305.1391074415327.JavaMail.root@openwide.fr>
Hello everybody
Buildroot is currently in the process of cleanly separating files
that are generated by buildroot and are throwaway files (in the
output directory) from files that are configuration files (the
BR2_EXTERNAL directory)
However the .config files used by buildroot and other kconfig
enabled software are not dealt with in a way that is consistant.
.config is the main buildroot configuration file. This is, more
than anything else "the project." It is the file we want to
keep in git, share within a software project, be warned in
case of conflict. However it is currently savedin the output
directory.
I am sending this mail to understand how the community see this
file, if there is something that needs to be changed to follow
the new separation and see what I can do to get this going.
(I will focus only in the buildroot .config file, the kernel,
busybox and uclibc ones can be worked out after that)
so, I have been looking around and there are a couple of
approches I can think of...
* keep the current approch
.config is considered a throw away file, it is logical that
it is in output/ and it is normal that it is destroyed on a
regular basis.
I don't like this too much because, for a final product, it
is the most important file, and a file that needs to be
kept in git. I don't think it is very logical to have such
an important file be a hidden file and be in a directory that
is meant to be removed.
* keep the file as $(CONFIG_DIR)/.config, but document that
CONFIG_DIR can be overridden
This keeps the file as a hidden file, but it allows us to
move it out of the output directory. Maybe CONFIG_DIR should
default to BR2_EXTERNAL instead of output/ (with some
backward compatibility layer)
* allow to override the configuration file with env variables
Basically allow overriding BUILDROOT_CONFIG from the command
line. This would solve all the problems I have but I am not
sure it follows the buildroot philosophy, thus the long mail.
This could be a subject for the buildroot days. If other people
are interested I can add it to the list of topics...
(note that I tried moving the kernel/busybox .config and it's
more tricky than the buildroot one... maybe we need a generic
infrastructure for kconfig enabled packages...)
Regards
J?r?my Rosen
fight key loggers : write some perl using vim
Open Wide Ingenierie
23, rue Daviel
75013 Paris - France
www.openwide.fr
next parent reply other threads:[~2014-01-30 9:53 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 ` Jeremy Rosen [this message]
2014-01-30 9:59 ` [Buildroot] Project layout : where to put the .config files 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
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=153768653.4890423.1391075638245.JavaMail.root@openwide.fr \
--to=jeremy.rosen@openwide.fr \
--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