From: "Jérôme Pouiller" <jezz@sysmic.org>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH RFC] Makefile: from a defconfig file, point to the corresponding board/ entry
Date: Fri, 28 Nov 2014 09:52:27 +0100 [thread overview]
Message-ID: <67490309.d6XZUb5mJs@aquila> (raw)
In-Reply-To: <20141127174628.GA3900@free.fr>
Hello Yann,
On Thursday 27 November 2014 18:46:28 Yann E. MORIN wrote:
> J?r?me, All,
>
> On 2014-11-27 11:26 +0100, J?r?me Pouiller spake thusly:
> > On Thursday 27 November 2014 00:13:55 Yann E. MORIN wrote:
> > > This is an RFC!
> > >
> > > When configuring Buildroot from a defconfig files, soem users complain
> > > it is non-obvious that the corresponding board documentattion is to be
> > > found in the board/ sub-directory.
> > >
> > > So, deduce the board name from the defconfig file, look for a similarly
> > > named sub-dir of board (first level only), and if such a directory
> > > exists, print a message stating extra documentation for that board is to
> > > be found there.
> >
> > What about introducing a BR2_BOARD_DIR configuration variable? This
> > variable>
> > would have two functions:
> > - May be used to locate other files (configs, overlays, etc...)
> > - If defined, a help message is displayed when this defconfig is
> > loaded.
>
> The problem with using a Kconfig string variable is that Kconfig strgings
> that have no prompt can only take their default value, as defined in
> Config.in; if there is no default value, then the string option is not
> even stored in the .config file.
Why should we hide this configuration variable?
--
J?r?me Pouiller, Sysmic
Embedded Linux specialist
http://www.sysmic.fr
next prev parent reply other threads:[~2014-11-28 8:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-26 23:13 [Buildroot] [PATCH RFC] Makefile: from a defconfig file, point to the corresponding board/ entry Yann E. MORIN
2014-11-27 10:26 ` Jérôme Pouiller
2014-11-27 17:46 ` Yann E. MORIN
2014-11-28 8:52 ` Jérôme Pouiller [this message]
2014-11-27 10:37 ` Thomas De Schampheleire
2014-11-27 10:41 ` Gustavo Zacarias
2014-11-27 17:47 ` Yann E. MORIN
2014-11-27 17:58 ` Yann E. MORIN
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=67490309.d6XZUb5mJs@aquila \
--to=jezz@sysmic.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.