[Buildroot] [PATCH next v4 6/6] core: implement per-package SDK and target

Andreas Naumann dev at andin.de
Mon Nov 19 14:27:59 UTC 2018


Am 19.11.18 um 11:48 schrieb Thomas Petazzoni:
> Hello,
> On Sun, 18 Nov 2018 22:55:26 +0100, Arnout Vandecappelle wrote:
>>> Yes, we got bitten pretty hard when preparing the kconfig infra. But
>>> what can we remember from an almost-5-year old work initiated after
>>> FOSDEM? ;-)
>>>> The goal is that one can run 'make foo-menuconfig' from a clean tree,
>>>> without first processing (downloading, building, ...) the dependencies
>>>> of foo first.
>>>> If you put this stuff in the configure step of foo, you are bound byi
>>>> its dependencies. There may be other reasons too, not sure.
>>> I am all in favour of simplifying it if it can be made simpler by adding
>>> an official extra 'prepare' step, that exists for all types of package
>>> infras. This we'd have 4 levels of dependencies:
>>>   1- download dependencies
>>>   2- extract dependencies
>>>   3- prepare dependencies
>>>   4- configure dependencies
>>   I think your mixing two things here. The "prepare" that ThomasP is talking
>> about is really the PPD creation. The additional step for autoreconf or kconfig
>> is something else - it's a step with commands that are defined by the package
>> (infra).
> I don't think Yann is mixing things here. Indeed we are using the word
> "prepare" for two different things: preparing the PPD folder, and
> "doing some stuff before the configure step".
> For the PPD folder, some preparation currently occurs at the download
> step (for download dependencies), some preparation occurs at the
> extract step (for the extract dependencies) and some preparation occurs
> at the configuration step (for the normal dependencies).
> The issue with the kconfig infrastructure is that it creates a new type
> of dependency called "kconfig dependency", which should be ready to do
> all the kconfig-related activities, but that we want separate from the
> normal "configure dependencies" because we want to be able to do "make
> linux-menuconfig" or "make busybox-menuconfig" without having to wait
> for their dependencies to build.
> So what Yann is proposing is that instead of having this "kconfig
> dependency" stuff be shoe-horned into the dependency chain by
> pkg-kconfig.mk, we should promote it to a new step in the build steps.
> By the lack of better naming, Yann named that step "prepare", but it
> has nothing to do with "preparing PPD".
> Indeed, what we would do is:
>   1. Download step
>      Prepare PPD with download dependencies
>      Do the normal download stuff
>   2. Extract step
>      Prepare PPD with extract dependencies
>      Do the normal extract stuff
>   3. Patch step
>      Prepare PPD with patch dependencies
>      Do the normal patch stuff
>   4. Prepare step
>      Prepare PPD with the prepare dependencies
>      Do the prepare stuff (i.e only the kconfig stuff for now)
>   5. Configure step
>      Prepare PPD with the normal dependencies
>      Do the normal configure stuff
> Does that clarify Yann's proposal ?
> I personally find it OK, even though it's a bit annoying to introduce
> yet another step just for the sake of pkg-kconfig.
> Also: I would not move autoreconf into this prepare step, but keep it
> as it is today, within the configure step. I don't (today at least) see
> the point/usefulness of moving the autoreconf into this prepare step.

This is basically what i have done, but without explicitely introducing 
separate kconfig-dependencies, I hope this is readable:

 From cf583d9ed09c667f24f526edf890d81b374e1d83 Mon Sep 17 00:00:00 2001
From: Andreas Naumann <anaumann at ultratronik.de>
Date: Wed, 14 Nov 2018 17:27:31 +0100
Subject: [PATCH v2 1/1] core: Move per-package host preparation into 

Unfortunately, the kconfig infrastructure is running the 'make 
step before the configure-step is "officially" started. This is due to
the kconfig_fixup target.
This however requires availability of the toolchain and other prerequisites,
so this patch introduces an intermediate target to prepare the per-package
host dir.

Signed-off-by: Andreas Naumann <anaumann at ultratronik.de>
  package/pkg-generic.mk | 19 +++++++++++++++----
  package/pkg-kconfig.mk |  2 +-
  2 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/package/pkg-generic.mk b/package/pkg-generic.mk
index 8ec5e8db73..3014c13846 100644
--- a/package/pkg-generic.mk
+++ b/package/pkg-generic.mk
@@ -232,11 +232,18 @@ $(foreach dir,$(call qstrip,$(BR2_GLOBAL_PATCH_DIR)),\
  	$(if $(wildcard $(dir)),,\
  		$(error BR2_GLOBAL_PATCH_DIR contains nonexistent directory $(dir))))

+# Prepare per-package host dir for configure
+	@$(call step_start,configure_prepared)
+	@$(call MESSAGE,"Prepare per-package host")
+	$(call prepare-per-package-folder,$($(PKG)_FINAL_DEPENDENCIES))
+	@$(call step_end,configure_prepared)
+	$(Q)touch $@
  # Configure
  	@$(call step_start,configure)
  	@$(call MESSAGE,"Configuring")
-	$(call prepare-per-package-folder,$($(PKG)_FINAL_DEPENDENCIES))
  	$(foreach hook,$($(PKG)_PRE_CONFIGURE_HOOKS),$(call $(hook))$(sep))
  	$(foreach hook,$($(PKG)_POST_CONFIGURE_HOOKS),$(call $(hook))$(sep))
@@ -663,6 +670,7 @@ $(2)_TARGET_INSTALL_STAGING = 
  $(2)_TARGET_INSTALL_IMAGES =	$$($(2)_DIR)/.stamp_images_installed
  $(2)_TARGET_INSTALL_HOST =      $$($(2)_DIR)/.stamp_host_installed
  $(2)_TARGET_BUILD =		$$($(2)_DIR)/.stamp_built
+$(2)_TARGET_CONFIGURE_PREP =	$$($(2)_DIR)/.stamp_configure_prepared
  $(2)_TARGET_CONFIGURE =		$$($(2)_DIR)/.stamp_configured
  $(2)_TARGET_RSYNC =	        $$($(2)_DIR)/.stamp_rsynced
  $(2)_TARGET_PATCH =		$$($(2)_DIR)/.stamp_patched
@@ -756,7 +764,8 @@ $$($(2)_TARGET_BUILD):	$$($(2)_TARGET_CONFIGURE)
  # dependency by using |.

  $(1)-configure:			$$($(2)_TARGET_CONFIGURE)

  $$($(2)_TARGET_SOURCE) $$($(2)_TARGET_RSYNC): | prepare
  $$($(2)_TARGET_SOURCE) $$($(2)_TARGET_RSYNC): | dependencies
@@ -768,7 +777,7 @@ ifeq ($$($(2)_OVERRIDE_SRCDIR),)
  #  extract
  #  patch
  #  configure

  $(1)-patch:		$$($(2)_TARGET_PATCH)
  $$($(2)_TARGET_PATCH):	$$($(2)_TARGET_EXTRACT)
@@ -807,7 +816,7 @@ else

  # Use an order-only dependency so the "<pkg>-clean-for-rebuild" rule
  # can remove the stamp file without triggering the configure step.

  $(1)-depends:		$$($(2)_FINAL_DEPENDENCIES)

@@ -878,6 +887,7 @@ $(1)-rebuild:		$(1)-clean-for-rebuild $(1)

  $(1)-clean-for-reconfigure: $(1)-clean-for-rebuild
  			rm -f $$($(2)_TARGET_CONFIGURE)
+			rm -f $$($(2)_TARGET_CONFIGURE_PREP)

  $(1)-reconfigure:	$(1)-clean-for-reconfigure $(1)

@@ -889,6 +899,7 @@ $$($(2)_TARGET_INSTALL_IMAGES):		PKG=$(2)
  $$($(2)_TARGET_INSTALL_HOST):		PKG=$(2)
  $$($(2)_TARGET_BUILD):			PKG=$(2)
  $$($(2)_TARGET_CONFIGURE):		PKG=$(2)
  $$($(2)_TARGET_RSYNC):			PKG=$(2)
  $$($(2)_TARGET_PATCH):			PKG=$(2)
diff --git a/package/pkg-kconfig.mk b/package/pkg-kconfig.mk
index d6c95b897e..5567df01d6 100644
--- a/package/pkg-kconfig.mk
+++ b/package/pkg-kconfig.mk
@@ -128,7 +128,7 @@ $$($(2)_DIR)/$$($(2)_KCONFIG_DOTCONFIG): | $(1)-patch
  # Some packages may need additional tools to be present by the time their
  # kconfig structure is parsed (e.g. the linux kernel may need to call to
  # the compiler to test its features).

  # In order to get a usable, consistent configuration, some fixup may 
be needed.
  # The exact rules are specified by the package .mk file.

> Best regards,
> Thomas

More information about the buildroot mailing list