All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] Linux extension from a BR2_EXTERNAL tree
Date: Mon, 28 Jan 2019 17:25:11 +0100	[thread overview]
Message-ID: <20190128172511.754500e4@windsurf> (raw)

Hello,

I am trying to implement a Linux extension, which applies a bunch of
patches to the Linux kernel tree, as a package in a BR2_EXTERNAL tree.
So, I have a package in my BR2_EXTERNAL that does this:

ifeq ($(BR2_PACKAGE_MUSDK_MARVELL_KERNEL_PATCHES_APPLY),y)
LINUX_EXTENSIONS += musdk-marvell

ifeq ($(BR2_PACKAGE_MUSDK_MARVELL_KERNEL_PATCHES_LINUX),y)
MUSDK_MARVELL_KERNEL_PATCH_SERIES = linux
else ifeq ($(BR2_PACKAGE_MUSDK_MARVELL_KERNEL_PATCHES_LINUX_4_14),y)
MUSDK_MARVELL_KERNEL_PATCH_SERIES = linux-4.14
endif

define MUSDK_MARVELL_PREPARE_KERNEL
        $(APPLY_PATCHES) $(@D) $(MUSDK_MARVELL_DIR)/patches/$(MUSDK_MARVELL_KERNEL_PATCH_SERIES) *.patch
endef
endif

My package is properly listed in LINUX_PATCH_DEPENDENCIES:

$ make printvars VARS=LINUX_PATCH_DEPENDENCIES
LINUX_PATCH_DEPENDENCIES=           musdk-marvell

And in LINUX_PRE_PATCH_HOOKS:

$ make printvars VARS=LINUX_PRE_PATCH_HOOKS
LINUX_PRE_PATCH_HOOKS=            MUSDK_MARVELL_PREPARE_KERNEL

When I build the kernel, it does run the MUSDK_MARVELL_PREPARE_KERNEL
command, but the musdk-marvell dependency was not prepared up to its
patching step (it was not even extracted at all), causing the
MUSDK_MARVELL_PREPARE_KERNEL hook to fail.

So it seems like adding an entry to the LINUX_EXTENSIONS variable
*after* linux/linux.mk has been processed works fine for the hook
registration, but not for the dependency addition. This looks odd to
me. The generic-package infrastructure does seem to have all the
necessary double-dollars to make sure the evaluation is delayed to the
time of use, but it seems to not be sufficient.

I am missing something obvious here ? I am not sure if I'm seeing
something that's easily fixable, or something that is just plain
impossible due to how make works.

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

             reply	other threads:[~2019-01-28 16:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-28 16:25 Thomas Petazzoni [this message]
2019-01-28 16:59 ` [Buildroot] Linux extension from a BR2_EXTERNAL tree Arnout Vandecappelle
2019-01-28 17:12 ` Yann E. MORIN
2019-01-28 21:43   ` Ryan Barnett

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=20190128172511.754500e4@windsurf \
    --to=thomas.petazzoni@bootlin.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.