[Buildroot] BR2_EXTERNAL and linux-ext-*.mk

[Buildroot] BR2_EXTERNAL and linux-ext-*.mk

[Heiko Thiery]

Hi All,

I recently recognized that there is the support to have linux patches
located in the BR2_EXTERNAL/linux directory with
c26eafa96cabd597a5cce534133ee0ff996b800c.

While using this feature I noticed that in there seems to go something
wrong. Once a file that matchs linux/linux-ext-*.mk is detected the
LINUX_PKGDIR is set to the BR2_EXTERNAL/linux path and for example the
"0001-timeconst.pl-Eliminate-Perl-warning.patch.conditional" patch
fails because the path is no longer valid. Also the hash check for the
linux sources fails due to the same reason.

Following 2 "make-linux-patch" tries, the first ends without error and
the second show the error:



---------- without BR2_EXTERNAL/linux/linux-ext-xxx.mk:

# make linux-patch
>>> linux 5.4.13 Downloading
--2020-01-23 21:57:11--
https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.4.13.tar.xz
Aufl?sen des Hostnamens cdn.kernel.org (cdn.kernel.org)?
151.101.1.176, 151.101.65.176, 151.101.129.176, ...
Verbindungsaufbau zu cdn.kernel.org
(cdn.kernel.org)|151.101.1.176|:443 ? verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet ? 200 OK
L?nge: 109463864 (104M) [application/x-xz]
Wird in ?/home/hthiery/sources/test-linux/build/build/.linux-5.4.13.tar.xz.3jGhoi/output?
gespeichert.

/home/hthiery/sources/test-linux/build/build
100%[===========================================================================================>]
104,39M  5,52MB/s    in 12s

2020-01-23 21:57:23 (8,59 MB/s) -
?/home/hthiery/sources/test-linux/build/build/.linux-5.4.13.tar.xz.3jGhoi/output?
gespeichert [109463864/109463864]

linux-5.4.13.tar.xz: OK (sha256:
49fb29d96d7e7c1d7e6082701bd26bfddd0fbc87a796fb6ba6258bc5fd386ad7)
>>> linux 5.4.13 Extracting
xzcat /home/hthiery/sources/test-linux/buildroot/dl/linux/linux-5.4.13.tar.xz
| /home/hthiery/sources/test-linux/build/host/bin/tar
--strip-components=1 -C
/home/hthiery/sources/test-linux/build/build/linux-5.4.13   -xf -
>>> linux 5.4.13 Patching
if [ -f /home/hthiery/sources/test-linux/build/build/linux-5.4.13/tools/perf/Documentation/Makefile
]; then printf "%%:\n\t@:\n"
>/home/hthiery/sources/test-linux/build/build/linux-5.4.13/tools/perf/Documentation/GNUmakefile;
fi
for p in  ; do if test -d $p ; then
PATH=/home/hthiery/sources/test-linux/build/host/bin:$PATH
support/scripts/apply-patches.sh
/home/hthiery/sources/test-linux/build/build/linux-5.4.13 $p \*.patch
|| exit 1 ; else
PATH=/home/hthiery/sources/test-linux/build/host/bin:$PATH
support/scripts/apply-patches.sh
/home/hthiery/sources/test-linux/build/build/linux-5.4.13 `dirname $p`
`basename $p` || exit 1; fi done

# make printvars VARS=LINUX_PKGDIR
LINUX_PKGDIR=linux/
--------------------


----------  with BR2_EXTERNAL/linux/linux-ext-xxx.mk:

# make linux-patch
>>> linux 5.4.13 Downloading
--2020-01-23 21:59:54--
https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.4.13.tar.xz
Aufl?sen des Hostnamens cdn.kernel.org (cdn.kernel.org)?
151.101.1.176, 151.101.65.176, 151.101.129.176, ...
Verbindungsaufbau zu cdn.kernel.org
(cdn.kernel.org)|151.101.1.176|:443 ? verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet ? 200 OK
L?nge: 109463864 (104M) [application/x-xz]
Wird in ?/home/hthiery/sources/test-linux/build/build/.linux-5.4.13.tar.xz.QfCmJd/output?
gespeichert.

/home/hthiery/sources/test-linux/build/build
100%[===========================================================================================>]
104,39M  13,0MB/s    in 6,1s

2020-01-23 22:00:00 (17,0 MB/s) -
?/home/hthiery/sources/test-linux/build/build/.linux-5.4.13.tar.xz.QfCmJd/output?
gespeichert [109463864/109463864]

WARNING: no hash file for linux-5.4.13.tar.xz
>>> linux 5.4.13 Extracting
xzcat /home/hthiery/sources/test-linux/buildroot/dl/linux/linux-5.4.13.tar.xz
| /home/hthiery/sources/test-linux/build/host/bin/tar
--strip-components=1 -C
/home/hthiery/sources/test-linux/build/build/linux-5.4.13   -xf -
>>> linux 5.4.13 Patching
if [ -f /home/hthiery/sources/test-linux/build/build/linux-5.4.13/tools/perf/Documentation/Makefile
]; then printf "%%:\n\t@:\n"
>/home/hthiery/sources/test-linux/build/build/linux-5.4.13/tools/perf/Documentation/GNUmakefile;
fi
for p in  ; do if test -d $p ; then
PATH=/home/hthiery/sources/test-linux/build/host/bin:$PATH
support/scripts/apply-patches.sh
/home/hthiery/sources/test-linux/build/build/linux-5.4.13 $p \*.patch
|| exit 1 ; else
PATH=/home/hthiery/sources/test-linux/build/host/bin:$PATH
support/scripts/apply-patches.sh
/home/hthiery/sources/test-linux/build/build/linux-5.4.13 `dirname $p`
`basename $p` || exit 1; fi done
/bin/bash: /home/hthiery/sources/test-linux/buildroot-external-linux-test/linux//0001-timeconst.pl-Eliminate-Perl-warning.patch.conditional:
Datei oder Verzeichnis nicht gefunden

# 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?

--
Heiko

[Buildroot] BR2_EXTERNAL and linux-ext-*.mk

[Yann E. MORIN]

On 2020-01-23 22:08 +0100, Heiko Thiery spake thusly:
> Hi All,
> 
> I recently recognized that there is the support to have linux patches
> located in the BR2_EXTERNAL/linux directory with
> c26eafa96cabd597a5cce534133ee0ff996b800c.
> 
> While using this feature I noticed that in there seems to go something
> wrong. Once a file that matchs linux/linux-ext-*.mk is detected the
> LINUX_PKGDIR is set to the BR2_EXTERNAL/linux path and for example the
> "0001-timeconst.pl-Eliminate-Perl-warning.patch.conditional" patch
> fails because the path is no longer valid. Also the hash check for the
> linux sources fails due to the same reason.
> 
> Following 2 "make-linux-patch" tries, the first ends without error and
> the second show the error:
> 
> 
> 
> ---------- without BR2_EXTERNAL/linux/linux-ext-xxx.mk:
[--SNIP--]
> # make printvars VARS=LINUX_PKGDIR
> LINUX_PKGDIR=linux/
> --------------------
> 
> ----------  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).

As long as we did support only in-tree linux extensions, all was OK,
because we would only include Makefiles from the same directory as the
main linux.mk one, so LINUX_PKGDIR was set to the directory of the last
linux extension included, which was OK.

But now, we can include extensions from a br2-external tree, and that
last assumption breaks down.

When we added that support, we only thought about the name of the
package, which is set based on the latest component of the directory, so
it had to be 'linux'. But we completely forgot about the _PKGDIR
variable. The existing comment only spoke about the directory name, not
the full path, because FOO_PKGCDIR was only introduced after linux
extensions were.

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.

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).

Care to test and properly send: http://code.bulix.org/4fcw7l-1104853?raw

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] BR2_EXTERNAL and linux-ext-*.mk

[Arnout Vandecappelle]

 I had composed a longish mail with essentially the same contents, but Yann beat
me to it :-)

On 23/01/2020 22:44, Yann E. MORIN wrote:
> On 2020-01-23 22:08 +0100, Heiko Thiery spake thusly:
>> Hi All,
>>
>> I recently recognized that there is the support to have linux patches
>> located in the BR2_EXTERNAL/linux directory with
>> c26eafa96cabd597a5cce534133ee0ff996b800c.
>>
>> While using this feature I noticed that in there seems to go something
>> wrong. Once a file that matchs linux/linux-ext-*.mk is detected the
>> LINUX_PKGDIR is set to the BR2_EXTERNAL/linux path and for example the
>> "0001-timeconst.pl-Eliminate-Perl-warning.patch.conditional" patch
>> fails because the path is no longer valid. Also the hash check for the
>> linux sources fails due to the same reason.
>>
>> Following 2 "make-linux-patch" tries, the first ends without error and
>> the second show the error:
>>
>>
>>
>> ---------- without BR2_EXTERNAL/linux/linux-ext-xxx.mk:
> [--SNIP--]
>> # make printvars VARS=LINUX_PKGDIR
>> LINUX_PKGDIR=linux/
>> --------------------
>>
>> ----------  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'
     Contains the name of each makefile that is parsed by 'make', in the
     order in which it was parsed.  The name is appended just before
     'make' begins to parse the makefile.  Thus, if the first thing a
     makefile does is examine the last word in this variable, it will be
     the name of the current makefile.  Once the current makefile has
     used 'include', however, the last word will be the just-included
     makefile.


> As long as we did support only in-tree linux extensions, all was OK,
> because we would only include Makefiles from the same directory as the
> main linux.mk one, so LINUX_PKGDIR was set to the directory of the last
> linux extension included, which was OK.
> 
> But now, we can include extensions from a br2-external tree, and that
> last assumption breaks down.
> 
> When we added that support, we only thought about the name of the
> package, which is set based on the latest component of the directory, so
> it had to be 'linux'. But we completely forgot about the _PKGDIR
> variable. The existing comment only spoke about the directory name, not
> the full path, because FOO_PKGCDIR was only introduced after linux
> extensions were.

 Ah, that explains it. I didn't understand how it could ever have worked.


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

 Nice one!

 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.


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


 Regards,
 Arnout

> Care to test and properly send: http://code.bulix.org/4fcw7l-1104853?raw
> 
> Regards,
> Yann E. MORIN.
> 

[Buildroot] BR2_EXTERNAL and linux-ext-*.mk

[Heiko Thiery]

Hi Arnout,

Am Do., 23. Jan. 2020 um 23:07 Uhr schrieb Arnout Vandecappelle
<arnout@mind.be>:
>
>  I had composed a longish mail with essentially the same contents, but Yann beat
> me to it :-)
>
> On 23/01/2020 22:44, Yann E. MORIN wrote:
> > On 2020-01-23 22:08 +0100, Heiko Thiery spake thusly:
> >> Hi All,
> >>
> >> I recently recognized that there is the support to have linux patches
> >> located in the BR2_EXTERNAL/linux directory with
> >> c26eafa96cabd597a5cce534133ee0ff996b800c.
> >>
> >> While using this feature I noticed that in there seems to go something
> >> wrong. Once a file that matchs linux/linux-ext-*.mk is detected the
> >> LINUX_PKGDIR is set to the BR2_EXTERNAL/linux path and for example the
> >> "0001-timeconst.pl-Eliminate-Perl-warning.patch.conditional" patch
> >> fails because the path is no longer valid. Also the hash check for the
> >> linux sources fails due to the same reason.
> >>
> >> Following 2 "make-linux-patch" tries, the first ends without error and
> >> the second show the error:
> >>
> >>
> >>
> >> ---------- without BR2_EXTERNAL/linux/linux-ext-xxx.mk:
> > [--SNIP--]
> >> # make printvars VARS=LINUX_PKGDIR
> >> LINUX_PKGDIR=linux/
> >> --------------------
> >>
> >> ----------  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'
>      Contains the name of each makefile that is parsed by 'make', in the
>      order in which it was parsed.  The name is appended just before
>      'make' begins to parse the makefile.  Thus, if the first thing a
>      makefile does is examine the last word in this variable, it will be
>      the name of the current makefile.  Once the current makefile has
>      used 'include', however, the last word will be the just-included
>      makefile.
>
>
> > As long as we did support only in-tree linux extensions, all was OK,
> > because we would only include Makefiles from the same directory as the
> > main linux.mk one, so LINUX_PKGDIR was set to the directory of the last
> > linux extension included, which was OK.
> >
> > But now, we can include extensions from a br2-external tree, and that
> > last assumption breaks down.
> >
> > When we added that support, we only thought about the name of the
> > package, which is set based on the latest component of the directory, so
> > it had to be 'linux'. But we completely forgot about the _PKGDIR
> > variable. The existing comment only spoke about the directory name, not
> > the full path, because FOO_PKGCDIR was only introduced after linux
> > extensions were.
>
>  Ah, that explains it. I didn't understand how it could ever have worked.
>
>
> > 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.
>
>  Nice one!
>
>  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.
>
>
> > 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.
>

If you have a proposel how to do I can test that. Unfortunatly I'm not
so familiar with that "core" functionality to try/solve it by my own.

--
Heiko

>
>  Regards,
>  Arnout
>
> > Care to test and properly send: http://code.bulix.org/4fcw7l-1104853?raw
> >
> > Regards,
> > Yann E. MORIN.
> >

[Buildroot] BR2_EXTERNAL and linux-ext-*.mk

[Yann E. MORIN]

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.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] BR2_EXTERNAL and linux-ext-*.mk

[Arnout Vandecappelle]

On 24/01/2020 18:38, Yann E. MORIN wrote:
> 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?

 Of course not. All talk and no work, that's me.

 Regards,
 Arnout

[Buildroot] BR2_EXTERNAL and linux-ext-*.mk

[Yann E. MORIN]

Arnout, All,

On 2020-01-24 18:43 +0100, Arnout Vandecappelle spake thusly:
> On 24/01/2020 18:38, Yann E. MORIN wrote:
> > 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?
>  Of course not. All talk and no work, that's me.

I don't have anything more either. Your comment gave me hope you had...
Damn... ;-)

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] BR2_EXTERNAL and linux-ext-*.mk

[Heiko Thiery]

Hi Yann,

Am Do., 23. Jan. 2020 um 22:44 Uhr schrieb Yann E. MORIN
<yann.morin.1998@free.fr>:
>
> On 2020-01-23 22:08 +0100, Heiko Thiery spake thusly:
> > Hi All,
> >
> > I recently recognized that there is the support to have linux patches
> > located in the BR2_EXTERNAL/linux directory with
> > c26eafa96cabd597a5cce534133ee0ff996b800c.
> >
> > While using this feature I noticed that in there seems to go something
> > wrong. Once a file that matchs linux/linux-ext-*.mk is detected the
> > LINUX_PKGDIR is set to the BR2_EXTERNAL/linux path and for example the
> > "0001-timeconst.pl-Eliminate-Perl-warning.patch.conditional" patch
> > fails because the path is no longer valid. Also the hash check for the
> > linux sources fails due to the same reason.
> >
> > Following 2 "make-linux-patch" tries, the first ends without error and
> > the second show the error:
> >
> >
> >
> > ---------- without BR2_EXTERNAL/linux/linux-ext-xxx.mk:
> [--SNIP--]
> > # make printvars VARS=LINUX_PKGDIR
> > LINUX_PKGDIR=linux/
> > --------------------
> >
> > ----------  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).
>
> As long as we did support only in-tree linux extensions, all was OK,
> because we would only include Makefiles from the same directory as the
> main linux.mk one, so LINUX_PKGDIR was set to the directory of the last
> linux extension included, which was OK.
>
> But now, we can include extensions from a br2-external tree, and that
> last assumption breaks down.
>
> When we added that support, we only thought about the name of the
> package, which is set based on the latest component of the directory, so
> it had to be 'linux'. But we completely forgot about the _PKGDIR
> variable. The existing comment only spoke about the directory name, not
> the full path, because FOO_PKGCDIR was only introduced after linux
> extensions were.
>
> 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.
>
> 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).

Thank you for the detailed explanation. That make a lot of things more
clear to me.

> Care to test and properly send: http://code.bulix.org/4fcw7l-1104853?raw

I just tested the changes and indeed this solves the problem. How to
handle the change?

Should I open a bug in bugzilla for tracking?

> 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.  |
> '------------------------------^-------^------------------^--------------------'

BR
--
Heiko

[Buildroot] BR2_EXTERNAL and linux-ext-*.mk

[Yann E. MORIN]

Heiko, All,

On 2020-01-24 08:19 +0100, Heiko Thiery spake thusly:
> Am Do., 23. Jan. 2020 um 22:44 Uhr schrieb Yann E. MORIN
> <yann.morin.1998@free.fr>:
> > 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.
[--SNIP--]
> > > ----------  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/
> > > ----------
[--SNIP--]
> > Care to test and properly send: http://code.bulix.org/4fcw7l-1104853?raw
> I just tested the changes and indeed this solves the problem. How to
> handle the change?

Thanks for testing! I'll send a proper patch some time later tonight...

> Should I open a bug in bugzilla for tracking?

No need for that.

Thanks! :-)

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.  |
'------------------------------^-------^------------------^--------------------'