From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] Buildroot developer meeting report
Date: Wed, 7 Oct 2015 16:40:44 +0100 [thread overview]
Message-ID: <20151007154044.GA4030@free.fr> (raw)
In-Reply-To: <5611AC6C.3060007@mind.be>
Hello All,
On 2015-10-04 23:47 +0100, Arnout Vandecappelle spake thusly:
> As you will have noticed from the mailing list traffic, it's been a very busy
> two days at the Buildroot developer meeting in Dublin. You can find the full
> report at [1].
[--SNIP--]
As part of the discussions came the subject of supporting multiple
br2-external trees at once.
The proposal I sent earlier was deemed to introduce too much complexity,
and Peter suggested we do it with "a script that will generate a bunch
of symlinks into a single directory, and use that directory as the
traditional br2-external."
So, I've spent most of my spare time since then to try to implement that
proposal, and made quite some progress, up to the point that I believe
this is not a doable solution. Although it seems nice on paper, it is
broken by design.
For example, take those two br2-external trees as a simple example (only
interesting files are listed):
br2-ext-1/
external.mk
include $(BR2_EXTERNAL)/foo/foo.mk
foo/
foo.mk
blabla package stuff in here
br2-ext-2/
external.mk
include $(BR2_EXTERNAL)/*/*.mk
Now, when we create the "shadow copy" full of symlinks, we inevitably
have to include those two external.mk files, because they may contain
more than include statements (like custom local rules, or custom macros,
or whatever; we always said that users were free to provide "even custom
configuration options and make logic" in there).
Now, since we're using a shadow copy, BR2_EXTERNAL at runtime will be
pointing to that shadow copy, so what happens in that case is that the
second external.mk will re-include foo/foo.mk
So far, this is not really a problem. Except we now want to ensure that
a package is not defined multiple times, to avoid a br2-external tree
redefining a package in Buildroot or in another br2-external tree.
But since foo/foo.mk is included twice, the second time will trigger the
re-definition check and we would abort.
There are not many solutions to this, but the more we try to fix this,
the more complex and fragile the code is getting. And worse, it would
inevitably break existing br2-external trees, which we are trying hard
to keep working without modification to those.
So, I'm calling the symlink (or "shadow copy") solution a dead-end out of
which I can't see an easy path.
Input most welcome.
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
next prev parent reply other threads:[~2015-10-07 15:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-04 22:47 [Buildroot] Buildroot developer meeting report Arnout Vandecappelle
2015-10-07 15:40 ` Yann E. MORIN [this message]
-- strict thread matches above, loose matches on Subject: below --
2014-10-22 12:55 Arnout Vandecappelle
2014-10-24 19:32 ` Doug Kehn
2014-10-24 23:06 ` Yann E. MORIN
2014-12-30 20:47 ` Matthew Weber
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=20151007154044.GA4030@free.fr \
--to=yann.morin.1998@free.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