From: "Yann E. MORIN" <yann.morin.1998@free.fr>
To: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: David Lawson <david.lawson1@tx.rr.com>, buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH v3] Makefile: fix use of many br2-external trees
Date: Wed, 21 Sep 2022 20:28:35 +0200 [thread overview]
Message-ID: <20220921182835.GS1419013@scaer> (raw)
In-Reply-To: <20220921201320.0a7f80c0@windsurf>
Thomas, All,
On 2022-09-21 20:13 +0200, Thomas Petazzoni spake thusly:
> On Tue, 20 Sep 2022 21:46:45 +0200
> "Yann E. MORIN" <yann.morin.1998@free.fr> wrote:
[--SNIP--]
> > One of the rationale behind this code, is that we want the defconfig
> > files from br2-external trees further down the list, to override
> > defconfig files from those earlier in the list, even overriding the
> > defconfig files from Buildroot itself.
> This is the part I would like to challenge. Why do we want to allow
> BR2_EXTERNAL to override defconfigs from the main tree? We do not allow
> this for packages, why should we allow it for defconfigs?
This patch does not change the actual behaviour: we've been allowing
this for the past 6 years, we've documented it; all that patch does is
actually fix using more than 5 br2-external trees.
> To me, allowing the override of defconfigs is actually a bad idea: when
> you run "make foo_defconfig", it's no longer really clear which
> "foo_defconfig" is really going to be used. Yes, it's well defined, but
> it isn't "obvious".
I think initially, it was far simpler to do it that way, since we did
not have a list of defconfig files, and so we (ab)used make ability to
override a rule, to justify a simpler code on our side.
Changing that behaviour is now easier, now that we do have a list of
defconfig files, but if at all, that should be done in a follow-up
patch.
However, the multi br2-external support is there to cover one case: a
br2-xternal tree provides basic support for a board (e.g. by a team in
charge of the ardware support), and a second br2-external provides
defconfig for an actual product. In this case, given a board named
'foo', it is understanble that the harware guys name their defconfig
foo_defconfig, and that the product team also name their defconfig
foo_defconfig. So, I think allowing this overide is not a bad thing.
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
next prev parent reply other threads:[~2022-09-21 18:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-20 19:46 [Buildroot] [PATCH v3] Makefile: fix use of many br2-external trees Yann E. MORIN
2022-09-21 18:13 ` Thomas Petazzoni
2022-09-21 18:28 ` Yann E. MORIN [this message]
2022-09-21 18:32 ` Arnout Vandecappelle
2022-09-21 18:57 ` 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=20220921182835.GS1419013@scaer \
--to=yann.morin.1998@free.fr \
--cc=buildroot@buildroot.org \
--cc=david.lawson1@tx.rr.com \
--cc=thomas.petazzoni@bootlin.com \
/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.