Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Rosen <jeremy.rosen@openwide.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCHv3 2/5] core: allow external Config.in/makefile	code to be integrated
Date: Thu, 28 Nov 2013 10:37:27 +0100 (CET)	[thread overview]
Message-ID: <1745239489.15294056.1385631446992.JavaMail.root@openwide.fr> (raw)
In-Reply-To: <20131128094342.3f6c84e4@skate>



----- Mail original -----
> Dear Jeremy Rosen,
> 
> Please do not top post. This is considered bad practice on mailing
> lists.
> 
sorry, trying to adapt to the different habits of the different ML

usually it's ok to toppost when you don't comment the actual content...

i'll try to get it right next time.

> > on this particular one, if I remember correctly the kconfig
> > infrastructure
> > will not work correctly if one of the include is missing... so
> > shouldn't
> > your infrastructure check if $(BR2_EXTERNAL)/package/Config.in
> > exists, and create one if it doesn't ?
> 
> The idea is that:
> 
>  * If the user is specifying a BR2_EXTERNAL location, then this
>    location *must* contain a package/Config.in file. Even if it's
>    empty.
> 
>  * If the user is not specifying a BR2_EXTERNAL location, then we are
>    using support/dummy-external/ as a fake BR2_EXTERNAL, to ensure
>    that
>    package/Config.in exists.
> 
> There is no way to express in kconfig "include this file if it
> exists,

my idea was more along the line of "if we are setting BR2_EXTERNAL
and the file doesn't exist, then create an empty "Config.in" file
so the next call to make doesn't fail" 

this would be to avoid leaving the build system in a broken 
configuration after a call that sets up the build system for the
user.

I can see pro and cons on this idea, there is a risk in touching
a file the user is supposed to edit and the breakage itself could
be considered a good way to make sure the user go look into the 
file

but on the other hand, for simple use cases where the user doesn't
want to add new packages, but simply overlay a couple of config
files, creating a valid infrastructure from the start might be 
a good idea...

Cheers
Boucman

  reply	other threads:[~2013-11-28  9:37 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-27 22:31 [Buildroot] [PATCHv3 0/5] Keeping customizations outside the Buildroot tree with BR2_EXTERNAL Thomas Petazzoni
2013-11-27 22:31 ` [Buildroot] [PATCHv3 1/5] core: introduce the BR2_EXTERNAL variable Thomas Petazzoni
2013-11-28 21:50   ` Yann E. MORIN
2013-11-28 21:55     ` Yann E. MORIN
2013-11-28 22:29   ` Yann E. MORIN
2013-11-27 22:31 ` [Buildroot] [PATCHv3 2/5] core: allow external Config.in/makefile code to be integrated Thomas Petazzoni
2013-11-28  8:33   ` Jeremy Rosen
2013-11-28  8:43     ` Thomas Petazzoni
2013-11-28  9:37       ` Jeremy Rosen [this message]
2013-11-28 11:33         ` Thomas Petazzoni
2013-11-28 12:09           ` Ryan Barnett
2013-11-28 12:29             ` Thomas Petazzoni
2013-11-28 12:33               ` Ryan Barnett
2013-11-28 13:24   ` Samuel Martin
2013-11-28 13:37     ` Simon Dawson
2013-11-28 16:23     ` Thomas Petazzoni
2013-11-28 17:53       ` Samuel Martin
2013-11-28 18:20         ` Thomas Petazzoni
2013-11-28 20:04           ` Samuel Martin
2013-11-28 20:21             ` Thomas Petazzoni
2013-11-28 22:21               ` Yann E. MORIN
2013-11-29  8:38                 ` Thomas Petazzoni
2013-11-30 23:30                   ` Arnout Vandecappelle
2013-11-27 22:31 ` [Buildroot] [PATCHv3 3/5] core: allow external defconfigs to be used Thomas Petazzoni
2013-11-27 22:31 ` [Buildroot] [PATCHv3 4/5] docs/manual: add explanations about BR2_EXTERNAL Thomas Petazzoni
2013-11-27 22:31 ` [Buildroot] [PATCHv3 5/5] manual: fix manual generation with BR2_EXTERNAL support Thomas Petazzoni

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=1745239489.15294056.1385631446992.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