From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] BR2_EXTERNAL and linux-ext-*.mk
Date: Fri, 24 Jan 2020 18:38:09 +0100 [thread overview]
Message-ID: <20200124173809.GA32369@scaer> (raw)
In-Reply-To: <5f9b9342-a3bc-a24e-932e-f11460f28886@mind.be>
Arnout, All,
On 2020-01-23 23:07 +0100, Arnout Vandecappelle spake thusly:
> I had composed a longish mail with essentially the same contents, but Yann beat
> me to it :-)
Hehe! ;-)
> On 23/01/2020 22:44, Yann E. MORIN wrote:
> > On 2020-01-23 22:08 +0100, Heiko Thiery spake thusly:
> >> I recently recognized that there is the support to have linux patches
> >> located in the BR2_EXTERNAL/linux directory with
> >> c26eafa96cabd597a5cce534133ee0ff996b800c.
> >> ---------- with BR2_EXTERNAL/linux/linux-ext-xxx.mk:
> > [--SNIP--]
> >> # make printvars VARS=LINUX_PKGDIR
> >> LINUX_PKGDIR=/home/hthiery/sources/test-linux/buildroot-external-linux-test/linux/
> >> ----------
> >>
> >> Do I miss something here or is this a bug?
> >
> > This is a bug, but not a simple one.
> >
> > FOO_PKGDIR is set based on the last component of the $(MAKEFILES)
> > variable. That variables contains the list of Makefiles that have been
> > included, in the order they've been included, with the top-level
> > Makefile first (left-most), and the last one last (right-most).
>
> From the info page:
>
> 'MAKEFILE_LIST'
Yeah, that is MAKEFILE_LIST, not MAKEFILES (I'll admit I did not look it
up before replying)...
> > It turns out that we may have a way out: we do not really care about the
> > order the extensions are included, since all they do is register post
> > hooks. So, if we were to include the extensions from the br2-external
> > trees, then the in-tree ones, we'd be back to the original situation.
> I had thought of another workaround: replace $(LINUX_PKGDIR) with linux - we
> know that that is the name of the directory. _PKGDIR is used for only two
> things: to find the package patches (and linux has none), and to find the hash
> file. So we'll still loose the hash file.
linux has one conditional patch, which is exactly how Heiko noticed the
issue to beginn with.
> > This is still a bit flaky, because we may end up breaking this again in
> > the future, but I don;t have a better solution (well, we could also have
> > a dummy empty makefile fragment that we explicitly include just right
> > before callign the pkg-generic infra, but that's still fragile).
> I do have a better solution: my big delayed evaluation change. If most of the
> inner-generic-package evaluation is delayed until the end of makefile processing
> and we just set a few key variables (including _PKGDIR), then we can move the
> call to generic-package much earlier (i.e. before the linux-ext-* include).
>
> We can't do that now because linux-ext-* may add dependencies, and those have
> to be set before "$$($(2)_TARGET_CONFIGURE): | $$($(2)_FINAL_DEPENDENCIES)" is
> evaluated.
Except that rule wil ponly be extended much later, once eveything is
actually parsed.
Do you already have some code for that big overhaul, except for the
little snippet I provided and we discussed on a few months ago?
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. |
'------------------------------^-------^------------------^--------------------'
next prev parent reply other threads:[~2020-01-24 17:38 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-23 21:08 [Buildroot] BR2_EXTERNAL and linux-ext-*.mk Heiko Thiery
2020-01-23 21:44 ` Yann E. MORIN
2020-01-23 22:07 ` Arnout Vandecappelle
2020-01-24 8:01 ` Heiko Thiery
2020-01-24 17:38 ` Yann E. MORIN [this message]
2020-01-24 17:43 ` Arnout Vandecappelle
2020-01-24 17:55 ` Yann E. MORIN
2020-01-24 7:19 ` Heiko Thiery
2020-01-24 17:53 ` 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=20200124173809.GA32369@scaer \
--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