Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
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.  |
'------------------------------^-------^------------------^--------------------'

  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