From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] Package can create LINUX_FINAL_RECURSIVE_DEPENDENCIES
Date: Sun, 26 Jan 2020 08:50:46 +0100 [thread overview]
Message-ID: <20200126075046.GG32369@scaer> (raw)
In-Reply-To: <CAEyMn7b_ESWcZ8ZBQAVYHxyXNQHrQUGx--8QGD1C6jj+F1=2gA@mail.gmail.com>
Heiko, All,
On 2020-01-24 08:37 +0100, Heiko Thiery spake thusly:
> I have a custom package (MYPACKAGE) in my BR2_EXTERNAL. This package
> uses the "$(eval $(kernel-module))". In addition this package also
> adds a kernel patch hook via BR2_EXTERNAL/linux-ext-MYPACKAGE.mk.
>
> As far as I see MYPACKAGE depends on linux (due to kernel-module) and
> LINUX depends on MYPACKAGE due to the dependency created to
> LINUX_PATCH_DEPENDENCIES.
>
> ----
> # make linux-legal-info
> linux/linux.mk:578: *** Recursive variable
> 'LINUX_FINAL_RECURSIVE_DEPENDENCIES' references itself (eventually).
> Stop.
> make: *** [Makefile:23: _all] Error 2
> ----
>
> Is having a package that does both (linux kernel module and kernel
> patching) allowed?
The linux-extensions are only _PATCH_DEPENDENCIES, that is the packages
providing the extensions shall be extracted and patched before linux is
patched.
So, as far as a build is concerned, this does not cause a circular
dependency.
However, as you noticed later, this does generate a circular dependency,
like gathering the elgal-info.
> Can this be fixed?
No, that 'can't be, I'm afraid... :-/
> I think linux only need the
> dependency to the MYPACKAGE_EXTRACT because the patch is not a result
> of the build of this package.
This is already the case, see above.
> What do you think?
As a short-term solution, just provide towo packages: one that provides
the extension, one that provides the kernel module.
However, if your package provides a kernel patch, why does it not patch
the kernel with your new module to begin with, and have the module built
as part of the kernel build? After all, that's the whole point of linux
extensions: inject new code in the kernel build process.
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-26 7:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-24 7:37 [Buildroot] Package can create LINUX_FINAL_RECURSIVE_DEPENDENCIES Heiko Thiery
2020-01-24 8:21 ` Heiko Thiery
2020-01-24 8:39 ` Michael Walle
2020-01-26 7:50 ` Yann E. MORIN [this message]
2020-01-26 7:56 ` Heiko Thiery
2020-01-26 8:01 ` Heiko Thiery
2020-01-26 9:21 ` 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=20200126075046.GG32369@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