[Buildroot] [PATCH v4 0/3] Fix for top-level parallel make part 1

[Buildroot] [PATCH v4 0/3] Fix for top-level parallel make part 1

[Fabio Porcedda]

Hi all,
this is the first patch set for fixing top-level parallel make in buildroot,
the common problem scattered in buildroot's top-level makefile is that in the
rules it relies on the order of evaluation of the prerequisites,
to be able to use top-level parallel make instead of reling on the left to
right ordering of evaluation of the prerequisites we must add an explicit
rule to describe the dependencies.

With this patch set the package building seems to work fine with top-level
parallel make, example:

	make clean toolchain
	make BR2_JLEVEL= -j<n> <package-name list> 

Before to try that you have to remove the ".NOTPARALLEL" line in the top-level Makefile.

The part that remain to fix for top-level parallel make is the toolchain
building and targets after building all the packages, also i'm preparing patch to add + prefix to every line that call a sub-make.

Best regards
Fabio Porcedda

v4:
 - rebased over master
 - add Acked-by: Thomas Petazzoni on the third patch
 - changed the orderd of the patches
v3:
 - add back the patch "package: add toolchain dependency to
    inner-generic-package" because now is working fine.
 - add Acked-by: Arnout Vandecappelle to the third patch.
 - reworked the second patch following Arnout suggestions.
v2:
 - remove patch "package: add toolchain dependency to inner-generic-package"
   because was not working fine against recent toolchain changes.

Fabio Porcedda (3):
  package: add toolchain dependency to inner-generic-package
  pkg-generic: fix rules for top-level parallel make
  package/Makefile.in: add a way to don't force jobs in sub-make

 Makefile                 |  2 +-
 package/Makefile.in      |  2 +-
 package/pkg-autotools.mk |  3 ++-
 package/pkg-generic.mk   | 51 ++++++++++++++++++++++++------------------------
 package/uclibc/uclibc.mk |  3 ++-
 5 files changed, 32 insertions(+), 29 deletions(-)

-- 
1.8.4

[Buildroot] [PATCH v4 1/3] package: add toolchain dependency to inner-generic-package

[Fabio Porcedda]

This commit makes the dependency from the target toolchain explicit.
This way we can buid from command line a package that use
innger-generic-package right after the configuration phase, example:

	make clean <package-name>

This is a step forward top-level parallel make.

Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
---
 Makefile                 | 2 +-
 package/pkg-autotools.mk | 3 ++-
 package/pkg-generic.mk   | 6 +++++-
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index 3367a6a..2465bc9 100644
--- a/Makefile
+++ b/Makefile
@@ -398,7 +398,7 @@ prepare: $(BUILD_DIR)/buildroot-config/auto.conf
 
 toolchain: prepare dirs dependencies $(BASE_TARGETS)
 
-world: toolchain $(TARGETS_ALL)
+world: $(TARGETS_ALL)
 
 .PHONY: all world toolchain dirs clean distclean source outputmakefile \
 	legal-info legal-info-prepare legal-info-clean printvars \
diff --git a/package/pkg-autotools.mk b/package/pkg-autotools.mk
index b0eddde..aafa396 100644
--- a/package/pkg-autotools.mk
+++ b/package/pkg-autotools.mk
@@ -202,7 +202,8 @@ endef
 # This must be repeated from inner-generic-package, otherwise we get an empty
 # _DEPENDENCIES if _AUTORECONF is YES.  Also filter the result of _AUTORECONF
 # away from the non-host rule
-$(2)_DEPENDENCIES ?= $(filter-out host-automake host-autoconf host-libtool $(1),\
+$(2)_DEPENDENCIES ?= $(filter-out host-automake host-autoconf host-libtool \
+				host-toolchain $(1),\
     $(patsubst host-host-%,host-%,$(addprefix host-,$($(3)_DEPENDENCIES))))
 
 
diff --git a/package/pkg-generic.mk b/package/pkg-generic.mk
index bfc4dc1..d7efcd3 100644
--- a/package/pkg-generic.mk
+++ b/package/pkg-generic.mk
@@ -307,7 +307,11 @@ endif
 $(2)_REDISTRIBUTE		?= YES
 
 
-$(2)_DEPENDENCIES ?= $(filter-out $(1),$(patsubst host-host-%,host-%,$(addprefix host-,$($(3)_DEPENDENCIES))))
+$(2)_DEPENDENCIES ?= $(filter-out  host-toolchain $(1),\
+	$(patsubst host-host-%,host-%,$(addprefix host-,$($(3)_DEPENDENCIES))))
+ifeq ($$($(2)_TYPE),target)
+$(2)_DEPENDENCIES += toolchain
+endif
 
 $(2)_INSTALL_STAGING		?= NO
 $(2)_INSTALL_IMAGES		?= NO
-- 
1.8.4

[Buildroot] [PATCH v4 2/3] pkg-generic: fix rules for top-level parallel make

[Fabio Porcedda]

To be able to use top-level parallel make we must don't depend in a rule
on the order of evaluation of the prerequisites, so instead of reling on
the left to right ordering of evaluation of the prerequisites add
an explicit rule to describe the dependencies.

So add explicit dependencies for the following stamp files:
   %/.stamp_extracted
   %/.stamp_patched
   %/.stamp_configured
   %/.stamp_built
   %/.stamp_host_installed
   %/.stamp_staging_installed
   %/.stamp_images_installed
   %/.stamp_target_installed

Because the %-build target is not anymore part of the dependcy chain,
add a new variable <pkgname>_BUILD_DEPENDENCIES to be used instead.
This new variable is used only by the uclibc package for building
the toolchain.

Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
---
 package/pkg-generic.mk   | 45 +++++++++++++++++++++------------------------
 package/uclibc/uclibc.mk |  3 ++-
 2 files changed, 23 insertions(+), 25 deletions(-)

diff --git a/package/pkg-generic.mk b/package/pkg-generic.mk
index d7efcd3..df6fa6f 100644
--- a/package/pkg-generic.mk
+++ b/package/pkg-generic.mk
@@ -53,7 +53,7 @@ ifeq ($(DL_MODE),DOWNLOAD)
 endif
 
 # Unpack the archive
-$(BUILD_DIR)/%/.stamp_extracted:
+$(BUILD_DIR)/%/.stamp_extracted: $(BUILD_DIR)/%/.stamp_downloaded
 	@$(call MESSAGE,"Extracting")
 	$(Q)mkdir -p $(@D)
 	$($(PKG)_EXTRACT_CMDS)
@@ -88,7 +88,7 @@ endif
 # prefix of the patches
 $(BUILD_DIR)/%/.stamp_patched: NAMEVER = $(RAWNAME)-$($(PKG)_VERSION)
 $(BUILD_DIR)/%/.stamp_patched: PATCH_BASE_DIRS = $($(PKG)_DIR_PREFIX)/$(RAWNAME) $(call qstrip,$(BR2_GLOBAL_PATCH_DIR))/$(RAWNAME)
-$(BUILD_DIR)/%/.stamp_patched:
+$(BUILD_DIR)/%/.stamp_patched: $(BUILD_DIR)/%/.stamp_extracted
 	@$(call MESSAGE,"Patching $($(PKG)_DIR_PREFIX)/$(RAWNAME)")
 	$(foreach hook,$($(PKG)_PRE_PATCH_HOOKS),$(call $(hook))$(sep))
 	$(foreach p,$($(PKG)_PATCH),support/scripts/apply-patches.sh $(@D) $(DL_DIR) $(notdir $(p))$(sep))
@@ -115,21 +115,21 @@ $(BUILD_DIR)/%/.stamp_configured:
 	$(Q)touch $@
 
 # Build
-$(BUILD_DIR)/%/.stamp_built::
+$(BUILD_DIR)/%/.stamp_built:	$(BUILD_DIR)/%/.stamp_configured
 	@$(call MESSAGE,"Building")
 	$($(PKG)_BUILD_CMDS)
 	$(foreach hook,$($(PKG)_POST_BUILD_HOOKS),$(call $(hook))$(sep))
 	$(Q)touch $@
 
 # Install to host dir
-$(BUILD_DIR)/%/.stamp_host_installed:
+$(BUILD_DIR)/%/.stamp_host_installed:		$(BUILD_DIR)/%/.stamp_built
 	@$(call MESSAGE,"Installing to host directory")
 	$($(PKG)_INSTALL_CMDS)
 	$(foreach hook,$($(PKG)_POST_INSTALL_HOOKS),$(call $(hook))$(sep))
 	$(Q)touch $@
 
 # Install to staging dir
-$(BUILD_DIR)/%/.stamp_staging_installed:
+$(BUILD_DIR)/%/.stamp_staging_installed:	$(BUILD_DIR)/%/.stamp_built
 	@$(call MESSAGE,"Installing to staging directory")
 	$($(PKG)_INSTALL_STAGING_CMDS)
 	$(foreach hook,$($(PKG)_POST_INSTALL_STAGING_HOOKS),$(call $(hook))$(sep))
@@ -143,14 +143,14 @@ $(BUILD_DIR)/%/.stamp_staging_installed:
 	$(Q)touch $@
 
 # Install to images dir
-$(BUILD_DIR)/%/.stamp_images_installed:
+$(BUILD_DIR)/%/.stamp_images_installed:		$(BUILD_DIR)/%/.stamp_built
 	@$(call MESSAGE,"Installing to images directory")
 	$($(PKG)_INSTALL_IMAGES_CMDS)
 	$(foreach hook,$($(PKG)_POST_INSTALL_IMAGES_HOOKS),$(call $(hook))$(sep))
 	$(Q)touch $@
 
 # Install to target dir
-$(BUILD_DIR)/%/.stamp_target_installed:
+$(BUILD_DIR)/%/.stamp_target_installed:		$(BUILD_DIR)/%/.stamp_built
 	@$(call MESSAGE,"Installing to target")
 	$(if $(BR2_INIT_SYSTEMD),\
 		$($(PKG)_INSTALL_INIT_SYSTEMD))
@@ -312,6 +312,7 @@ $(2)_DEPENDENCIES ?= $(filter-out  host-toolchain $(1),\
 ifeq ($$($(2)_TYPE),target)
 $(2)_DEPENDENCIES += toolchain
 endif
+$(2)_BUILD_DEPENDENCIES		?=
 
 $(2)_INSTALL_STAGING		?= NO
 $(2)_INSTALL_IMAGES		?= NO
@@ -363,30 +364,29 @@ $(1)-install:		$(1)-install-staging $(1)-install-target $(1)-install-images
 endif
 
 ifeq ($$($(2)_INSTALL_TARGET),YES)
-$(1)-install-target:	$(1)-build \
-			$$($(2)_TARGET_INSTALL_TARGET)
+$(1)-install-target:	$$($(2)_TARGET_INSTALL_TARGET)
 else
 $(1)-install-target:
 endif
 
 ifeq ($$($(2)_INSTALL_STAGING),YES)
-$(1)-install-staging:	$(1)-build \
-			$$($(2)_TARGET_INSTALL_STAGING)
+$(1)-install-staging:	$$($(2)_TARGET_INSTALL_STAGING)
 else
 $(1)-install-staging:
 endif
 
 ifeq ($$($(2)_INSTALL_IMAGES),YES)
-$(1)-install-images:	$(1)-build \
-			$$($(2)_TARGET_INSTALL_IMAGES)
+$(1)-install-images:	$$($(2)_TARGET_INSTALL_IMAGES)
 else
 $(1)-install-images:
 endif
 
-$(1)-install-host:      $(1)-build $$($(2)_TARGET_INSTALL_HOST)
+$(1)-install-host:      $$($(2)_TARGET_INSTALL_HOST)
 
-$(1)-build:		$(1)-configure \
-			$$($(2)_TARGET_BUILD)
+$$($(2)_TARGET_BUILD):	| $$($(2)_BUILD_DEPENDENCIES)
+$(1)-build:		$$($(2)_TARGET_BUILD)
+
+$(1)-configure:		$$($(2)_TARGET_CONFIGURE)
 
 ifeq ($$($(2)_OVERRIDE_SRCDIR),)
 # In the normal case (no package override), the sequence of steps is
@@ -395,13 +395,11 @@ ifeq ($$($(2)_OVERRIDE_SRCDIR),)
 #  extract
 #  patch
 #  configure
-$(1)-configure:		$(1)-patch $(1)-depends \
-			$$($(2)_TARGET_CONFIGURE)
+$$($(2)_TARGET_CONFIGURE):	| $$($(2)_DEPENDENCIES) $$($(2)_TARGET_PATCH)
 
-$(1)-patch:		$(1)-extract $$($(2)_TARGET_PATCH)
+$(1)-patch:		$$($(2)_TARGET_PATCH)
 
-$(1)-extract:		$(1)-source \
-			$$($(2)_TARGET_EXTRACT)
+$(1)-extract:		$$($(2)_TARGET_EXTRACT)
 
 $(1)-depends:		$$($(2)_DEPENDENCIES)
 
@@ -411,10 +409,9 @@ else
 #  source, by rsyncing
 #  depends
 #  configure
-$(1)-configure:		$(1)-depends \
-			$$($(2)_TARGET_CONFIGURE)
+$$($(2)_TARGET_CONFIGURE):	| $$($(2)_DEPENDENCIES) $$($(2)_TARGET_RSYNC)
 
-$(1)-depends:		$(1)-rsync $$($(2)_DEPENDENCIES)
+$(1)-depends:		$$($(2)_DEPENDENCIES)
 
 $(1)-patch:		$(1)-rsync
 $(1)-extract:		$(1)-rsync
diff --git a/package/uclibc/uclibc.mk b/package/uclibc/uclibc.mk
index 181a772..8ae0e26 100644
--- a/package/uclibc/uclibc.mk
+++ b/package/uclibc/uclibc.mk
@@ -24,7 +24,8 @@ UCLIBC_DEPENDENCIES = host-gcc-initial linux-headers
 
 # Before uClibc is built, we must have the second stage
 # cross-compiler, for some gcc versions, and when NPTL is used.
-uclibc-build: $(if $(BR2_TOOLCHAIN_NEEDS_THREE_STAGE_BUILD),host-gcc-intermediate)
+UCLIBC_BUILD_DEPENDENCIES = \
+	$(if $(BR2_TOOLCHAIN_NEEDS_THREE_STAGE_BUILD),host-gcc-intermediate)
 
 # specifying UCLIBC_CONFIG_FILE on the command-line overrides the .config
 # setting.
-- 
1.8.4

[Buildroot] [PATCH v4 3/3] package/Makefile.in: add a way to don't force jobs in sub-make

[Fabio Porcedda]

When the "BR2_JLEVEL" variable is empty use "make"
without the "-j" option.
To be able to use top-level parallel make we must don't force
the number of jobs in sub-make.

Example:
	make BR2_JLEVEL= -j8

Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 package/Makefile.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/Makefile.in b/package/Makefile.in
index 170ad78..d406901 100644
--- a/package/Makefile.in
+++ b/package/Makefile.in
@@ -18,7 +18,7 @@ PARALLEL_JOBS:=$(BR2_JLEVEL)
 endif
 
 MAKE1:=$(HOSTMAKE) -j1
-MAKE:=$(HOSTMAKE) -j$(PARALLEL_JOBS)
+MAKE:=$(HOSTMAKE) $(if $(PARALLEL_JOBS),-j$(PARALLEL_JOBS))
 
 # Compute GNU_TARGET_NAME
 GNU_TARGET_NAME=$(ARCH)-buildroot-$(TARGET_OS)-$(LIBC)$(ABI)
-- 
1.8.4

[Buildroot] [PATCH v4 3/3] package/Makefile.in: add a way to don't force jobs in sub-make

[Thomas Petazzoni]

Dear Fabio Porcedda,

That's a minor nit, but "add a way to don't force jobs in sub-make"
isn't really correct english I blieve. "add away to not force the
number of jobs in sub-make" or something like that would be more
appropriate.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH v4 2/3] pkg-generic: fix rules for top-level parallel make

[Thomas Petazzoni]

Dear Fabio Porcedda,

On Tue, 17 Sep 2013 09:59:12 +0200, Fabio Porcedda wrote:
> To be able to use top-level parallel make we must don't depend in a rule

must don't -> should not

> on the order of evaluation of the prerequisites, so instead of reling on

reling -> relying

> the left to right ordering of evaluation of the prerequisites add
> an explicit rule to describe the dependencies.
> 
> So add explicit dependencies for the following stamp files:
>    %/.stamp_extracted
>    %/.stamp_patched
>    %/.stamp_configured
>    %/.stamp_built
>    %/.stamp_host_installed
>    %/.stamp_staging_installed
>    %/.stamp_images_installed
>    %/.stamp_target_installed
> 
> Because the %-build target is not anymore part of the dependcy chain,

dependency

> add a new variable <pkgname>_BUILD_DEPENDENCIES to be used instead.
> This new variable is used only by the uclibc package for building
> the toolchain.
> 
> Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
> ---
>  package/pkg-generic.mk   | 45 +++++++++++++++++++++------------------------
>  package/uclibc/uclibc.mk |  3 ++-
>  2 files changed, 23 insertions(+), 25 deletions(-)
> 
> diff --git a/package/pkg-generic.mk b/package/pkg-generic.mk
> index d7efcd3..df6fa6f 100644
> --- a/package/pkg-generic.mk
> +++ b/package/pkg-generic.mk
> @@ -53,7 +53,7 @@ ifeq ($(DL_MODE),DOWNLOAD)
>  endif
>  
>  # Unpack the archive
> -$(BUILD_DIR)/%/.stamp_extracted:
> +$(BUILD_DIR)/%/.stamp_extracted: $(BUILD_DIR)/%/.stamp_downloaded
>  	@$(call MESSAGE,"Extracting")
>  	$(Q)mkdir -p $(@D)
>  	$($(PKG)_EXTRACT_CMDS)
> @@ -88,7 +88,7 @@ endif
>  # prefix of the patches
>  $(BUILD_DIR)/%/.stamp_patched: NAMEVER = $(RAWNAME)-$($(PKG)_VERSION)
>  $(BUILD_DIR)/%/.stamp_patched: PATCH_BASE_DIRS = $($(PKG)_DIR_PREFIX)/$(RAWNAME) $(call qstrip,$(BR2_GLOBAL_PATCH_DIR))/$(RAWNAME)
> -$(BUILD_DIR)/%/.stamp_patched:
> +$(BUILD_DIR)/%/.stamp_patched: $(BUILD_DIR)/%/.stamp_extracted
>  	@$(call MESSAGE,"Patching $($(PKG)_DIR_PREFIX)/$(RAWNAME)")
>  	$(foreach hook,$($(PKG)_PRE_PATCH_HOOKS),$(call $(hook))$(sep))
>  	$(foreach p,$($(PKG)_PATCH),support/scripts/apply-patches.sh $(@D) $(DL_DIR) $(notdir $(p))$(sep))
> @@ -115,21 +115,21 @@ $(BUILD_DIR)/%/.stamp_configured:
>  	$(Q)touch $@
>  
>  # Build
> -$(BUILD_DIR)/%/.stamp_built::
> +$(BUILD_DIR)/%/.stamp_built:	$(BUILD_DIR)/%/.stamp_configured
>  	@$(call MESSAGE,"Building")
>  	$($(PKG)_BUILD_CMDS)
>  	$(foreach hook,$($(PKG)_POST_BUILD_HOOKS),$(call $(hook))$(sep))
>  	$(Q)touch $@
>  
>  # Install to host dir
> -$(BUILD_DIR)/%/.stamp_host_installed:
> +$(BUILD_DIR)/%/.stamp_host_installed:		$(BUILD_DIR)/%/.stamp_built
>  	@$(call MESSAGE,"Installing to host directory")
>  	$($(PKG)_INSTALL_CMDS)
>  	$(foreach hook,$($(PKG)_POST_INSTALL_HOOKS),$(call $(hook))$(sep))
>  	$(Q)touch $@
>  
>  # Install to staging dir
> -$(BUILD_DIR)/%/.stamp_staging_installed:
> +$(BUILD_DIR)/%/.stamp_staging_installed:	$(BUILD_DIR)/%/.stamp_built
>  	@$(call MESSAGE,"Installing to staging directory")
>  	$($(PKG)_INSTALL_STAGING_CMDS)
>  	$(foreach hook,$($(PKG)_POST_INSTALL_STAGING_HOOKS),$(call $(hook))$(sep))
> @@ -143,14 +143,14 @@ $(BUILD_DIR)/%/.stamp_staging_installed:
>  	$(Q)touch $@
>  
>  # Install to images dir
> -$(BUILD_DIR)/%/.stamp_images_installed:
> +$(BUILD_DIR)/%/.stamp_images_installed:		$(BUILD_DIR)/%/.stamp_built
>  	@$(call MESSAGE,"Installing to images directory")
>  	$($(PKG)_INSTALL_IMAGES_CMDS)
>  	$(foreach hook,$($(PKG)_POST_INSTALL_IMAGES_HOOKS),$(call $(hook))$(sep))
>  	$(Q)touch $@
>  
>  # Install to target dir
> -$(BUILD_DIR)/%/.stamp_target_installed:
> +$(BUILD_DIR)/%/.stamp_target_installed:		$(BUILD_DIR)/%/.stamp_built
>  	@$(call MESSAGE,"Installing to target")
>  	$(if $(BR2_INIT_SYSTEMD),\
>  		$($(PKG)_INSTALL_INIT_SYSTEMD))
> @@ -312,6 +312,7 @@ $(2)_DEPENDENCIES ?= $(filter-out  host-toolchain $(1),\
>  ifeq ($$($(2)_TYPE),target)
>  $(2)_DEPENDENCIES += toolchain
>  endif
> +$(2)_BUILD_DEPENDENCIES		?=
>  
>  $(2)_INSTALL_STAGING		?= NO
>  $(2)_INSTALL_IMAGES		?= NO
> @@ -363,30 +364,29 @@ $(1)-install:		$(1)-install-staging $(1)-install-target $(1)-install-images
>  endif
>  
>  ifeq ($$($(2)_INSTALL_TARGET),YES)
> -$(1)-install-target:	$(1)-build \
> -			$$($(2)_TARGET_INSTALL_TARGET)
> +$(1)-install-target:	$$($(2)_TARGET_INSTALL_TARGET)
>  else
>  $(1)-install-target:
>  endif
>  
>  ifeq ($$($(2)_INSTALL_STAGING),YES)
> -$(1)-install-staging:	$(1)-build \
> -			$$($(2)_TARGET_INSTALL_STAGING)
> +$(1)-install-staging:	$$($(2)_TARGET_INSTALL_STAGING)
>  else
>  $(1)-install-staging:
>  endif
>  
>  ifeq ($$($(2)_INSTALL_IMAGES),YES)
> -$(1)-install-images:	$(1)-build \
> -			$$($(2)_TARGET_INSTALL_IMAGES)
> +$(1)-install-images:	$$($(2)_TARGET_INSTALL_IMAGES)
>  else
>  $(1)-install-images:
>  endif
>  
> -$(1)-install-host:      $(1)-build $$($(2)_TARGET_INSTALL_HOST)
> +$(1)-install-host:      $$($(2)_TARGET_INSTALL_HOST)
>  
> -$(1)-build:		$(1)-configure \
> -			$$($(2)_TARGET_BUILD)
> +$$($(2)_TARGET_BUILD):	| $$($(2)_BUILD_DEPENDENCIES)
> +$(1)-build:		$$($(2)_TARGET_BUILD)
> +
> +$(1)-configure:		$$($(2)_TARGET_CONFIGURE)
>  
>  ifeq ($$($(2)_OVERRIDE_SRCDIR),)
>  # In the normal case (no package override), the sequence of steps is
> @@ -395,13 +395,11 @@ ifeq ($$($(2)_OVERRIDE_SRCDIR),)
>  #  extract
>  #  patch
>  #  configure
> -$(1)-configure:		$(1)-patch $(1)-depends \
> -			$$($(2)_TARGET_CONFIGURE)
> +$$($(2)_TARGET_CONFIGURE):	| $$($(2)_DEPENDENCIES) $$($(2)_TARGET_PATCH)

Why is $$($(2)_TARGET_PATCH) an order-only dependency? Why isn't the
configure -> patch dependency handled like all the others, using stamp
files dependencies?

Note that I do understand the order-only dependency of
$(2)_TARGET_CONFIGURE on $(2)_DEPENDENCIES, but not on
$(2)_TARGET_PATCH.

> -$(1)-patch:		$(1)-extract $$($(2)_TARGET_PATCH)
> +$(1)-patch:		$$($(2)_TARGET_PATCH)
>  
> -$(1)-extract:		$(1)-source \
> -			$$($(2)_TARGET_EXTRACT)
> +$(1)-extract:		$$($(2)_TARGET_EXTRACT)
>  
>  $(1)-depends:		$$($(2)_DEPENDENCIES)
>  
> @@ -411,10 +409,9 @@ else
>  #  source, by rsyncing
>  #  depends
>  #  configure
> -$(1)-configure:		$(1)-depends \
> -			$$($(2)_TARGET_CONFIGURE)
> +$$($(2)_TARGET_CONFIGURE):	| $$($(2)_DEPENDENCIES) $$($(2)_TARGET_RSYNC)
>  
> -$(1)-depends:		$(1)-rsync $$($(2)_DEPENDENCIES)
> +$(1)-depends:		$$($(2)_DEPENDENCIES)
>  
>  $(1)-patch:		$(1)-rsync
>  $(1)-extract:		$(1)-rsync
> diff --git a/package/uclibc/uclibc.mk b/package/uclibc/uclibc.mk
> index 181a772..8ae0e26 100644
> --- a/package/uclibc/uclibc.mk
> +++ b/package/uclibc/uclibc.mk
> @@ -24,7 +24,8 @@ UCLIBC_DEPENDENCIES = host-gcc-initial linux-headers
>  
>  # Before uClibc is built, we must have the second stage
>  # cross-compiler, for some gcc versions, and when NPTL is used.
> -uclibc-build: $(if $(BR2_TOOLCHAIN_NEEDS_THREE_STAGE_BUILD),host-gcc-intermediate)
> +UCLIBC_BUILD_DEPENDENCIES = \
> +	$(if $(BR2_TOOLCHAIN_NEEDS_THREE_STAGE_BUILD),host-gcc-intermediate)
>  
>  # specifying UCLIBC_CONFIG_FILE on the command-line overrides the .config
>  # setting.

There is the same problem in package/glibc/glibc.mk.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH v4 3/3] package/Makefile.in: add a way to don't force jobs in sub-make

[Ciarán Rehill]

Maybe "add a way to prevent forcing of [parallel?] jobs in sub-make"?
On Sep 17, 2013 7:18 PM, "Thomas Petazzoni" <
thomas.petazzoni@free-electrons.com> wrote:

> Dear Fabio Porcedda,
>
> That's a minor nit, but "add a way to don't force jobs in sub-make"
> isn't really correct english I blieve. "add away to not force the
> number of jobs in sub-make" or something like that would be more
> appropriate.
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130917/0027b62d/attachment.html>

[Buildroot] [PATCH v4 3/3] package/Makefile.in: add a way to don't force jobs in sub-make

[Fabio Porcedda]

Hi Thomas and Clar?n,
thanks for reviewing.

On Tue, Sep 17, 2013 at 8:24 PM, Ciar?n Rehill <cir.vfi@gmail.com> wrote:
> Maybe "add a way to prevent forcing of [parallel?] jobs in sub-make"?
>
> On Sep 17, 2013 7:18 PM, "Thomas Petazzoni"
> <thomas.petazzoni@free-electrons.com> wrote:
>>
>> Dear Fabio Porcedda,
>>
>> That's a minor nit, but "add a way to don't force jobs in sub-make"
>> isn't really correct english I blieve. "add away to not force the
>> number of jobs in sub-make" or something like that would be more
>> appropriate.

What about a mix of both?
"add a way to prevent forcing the number of jobs in sub-make"

Thanks
-- 
Fabio Porcedda

[Buildroot] [PATCH v4 3/3] package/Makefile.in: add a way to don't force jobs in sub-make

[Thomas De Schampheleire]

Op 19-sep.-2013 08:35 schreef "Fabio Porcedda" <fabio.porcedda@gmail.com>
het volgende:
>
> Hi Thomas and Clar?n,
> thanks for reviewing.
>
> On Tue, Sep 17, 2013 at 8:24 PM, Ciar?n Rehill <cir.vfi@gmail.com> wrote:
> > Maybe "add a way to prevent forcing of [parallel?] jobs in sub-make"?
> >
> > On Sep 17, 2013 7:18 PM, "Thomas Petazzoni"
> > <thomas.petazzoni@free-electrons.com> wrote:
> >>
> >> Dear Fabio Porcedda,
> >>
> >> That's a minor nit, but "add a way to don't force jobs in sub-make"
> >> isn't really correct english I blieve. "add away to not force the
> >> number of jobs in sub-make" or something like that would be more
> >> appropriate.
>
> What about a mix of both?
> "add a way to prevent forcing the number of jobs in sub-make"
>

In fact, we don't add a way, since the user cannot choose to force or not.
So I'd suggest something like:
Don't force the number of jobs...
Or if you prefer:
Prevent forcing...

Best regards,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130919/2b41a970/attachment.html>

[Buildroot] [PATCH v4 2/3] pkg-generic: fix rules for top-level parallel make

[Fabio Porcedda]

Hi Thomas,
thanks for reviewing.

On Tue, Sep 17, 2013 at 8:23 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Fabio Porcedda,
>
> On Tue, 17 Sep 2013 09:59:12 +0200, Fabio Porcedda wrote:
>> To be able to use top-level parallel make we must don't depend in a rule
>
> must don't -> should not

Maybe "must not" because is a requirement and not a suggestion?

>
>> on the order of evaluation of the prerequisites, so instead of reling on
>
> reling -> relying

ok

>> the left to right ordering of evaluation of the prerequisites add
>> an explicit rule to describe the dependencies.
>>
>> So add explicit dependencies for the following stamp files:
>>    %/.stamp_extracted
>>    %/.stamp_patched
>>    %/.stamp_configured
>>    %/.stamp_built
>>    %/.stamp_host_installed
>>    %/.stamp_staging_installed
>>    %/.stamp_images_installed
>>    %/.stamp_target_installed
>>
>> Because the %-build target is not anymore part of the dependcy chain,
>
> dependency

ok

>> add a new variable <pkgname>_BUILD_DEPENDENCIES to be used instead.
>> This new variable is used only by the uclibc package for building
>> the toolchain.
>>
>> Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
>> ---
>>  package/pkg-generic.mk   | 45 +++++++++++++++++++++------------------------
>>  package/uclibc/uclibc.mk |  3 ++-
>>  2 files changed, 23 insertions(+), 25 deletions(-)
>>
>> diff --git a/package/pkg-generic.mk b/package/pkg-generic.mk
>> index d7efcd3..df6fa6f 100644
>> --- a/package/pkg-generic.mk
>> +++ b/package/pkg-generic.mk
>> @@ -53,7 +53,7 @@ ifeq ($(DL_MODE),DOWNLOAD)
>>  endif
>>
>>  # Unpack the archive
>> -$(BUILD_DIR)/%/.stamp_extracted:
>> +$(BUILD_DIR)/%/.stamp_extracted: $(BUILD_DIR)/%/.stamp_downloaded
>>       @$(call MESSAGE,"Extracting")
>>       $(Q)mkdir -p $(@D)
>>       $($(PKG)_EXTRACT_CMDS)
>> @@ -88,7 +88,7 @@ endif
>>  # prefix of the patches
>>  $(BUILD_DIR)/%/.stamp_patched: NAMEVER = $(RAWNAME)-$($(PKG)_VERSION)
>>  $(BUILD_DIR)/%/.stamp_patched: PATCH_BASE_DIRS = $($(PKG)_DIR_PREFIX)/$(RAWNAME) $(call qstrip,$(BR2_GLOBAL_PATCH_DIR))/$(RAWNAME)
>> -$(BUILD_DIR)/%/.stamp_patched:
>> +$(BUILD_DIR)/%/.stamp_patched: $(BUILD_DIR)/%/.stamp_extracted
>>       @$(call MESSAGE,"Patching $($(PKG)_DIR_PREFIX)/$(RAWNAME)")
>>       $(foreach hook,$($(PKG)_PRE_PATCH_HOOKS),$(call $(hook))$(sep))
>>       $(foreach p,$($(PKG)_PATCH),support/scripts/apply-patches.sh $(@D) $(DL_DIR) $(notdir $(p))$(sep))
>> @@ -115,21 +115,21 @@ $(BUILD_DIR)/%/.stamp_configured:
>>       $(Q)touch $@
>>
>>  # Build
>> -$(BUILD_DIR)/%/.stamp_built::
>> +$(BUILD_DIR)/%/.stamp_built: $(BUILD_DIR)/%/.stamp_configured
>>       @$(call MESSAGE,"Building")
>>       $($(PKG)_BUILD_CMDS)
>>       $(foreach hook,$($(PKG)_POST_BUILD_HOOKS),$(call $(hook))$(sep))
>>       $(Q)touch $@
>>
>>  # Install to host dir
>> -$(BUILD_DIR)/%/.stamp_host_installed:
>> +$(BUILD_DIR)/%/.stamp_host_installed:                $(BUILD_DIR)/%/.stamp_built
>>       @$(call MESSAGE,"Installing to host directory")
>>       $($(PKG)_INSTALL_CMDS)
>>       $(foreach hook,$($(PKG)_POST_INSTALL_HOOKS),$(call $(hook))$(sep))
>>       $(Q)touch $@
>>
>>  # Install to staging dir
>> -$(BUILD_DIR)/%/.stamp_staging_installed:
>> +$(BUILD_DIR)/%/.stamp_staging_installed:     $(BUILD_DIR)/%/.stamp_built
>>       @$(call MESSAGE,"Installing to staging directory")
>>       $($(PKG)_INSTALL_STAGING_CMDS)
>>       $(foreach hook,$($(PKG)_POST_INSTALL_STAGING_HOOKS),$(call $(hook))$(sep))
>> @@ -143,14 +143,14 @@ $(BUILD_DIR)/%/.stamp_staging_installed:
>>       $(Q)touch $@
>>
>>  # Install to images dir
>> -$(BUILD_DIR)/%/.stamp_images_installed:
>> +$(BUILD_DIR)/%/.stamp_images_installed:              $(BUILD_DIR)/%/.stamp_built
>>       @$(call MESSAGE,"Installing to images directory")
>>       $($(PKG)_INSTALL_IMAGES_CMDS)
>>       $(foreach hook,$($(PKG)_POST_INSTALL_IMAGES_HOOKS),$(call $(hook))$(sep))
>>       $(Q)touch $@
>>
>>  # Install to target dir
>> -$(BUILD_DIR)/%/.stamp_target_installed:
>> +$(BUILD_DIR)/%/.stamp_target_installed:              $(BUILD_DIR)/%/.stamp_built
>>       @$(call MESSAGE,"Installing to target")
>>       $(if $(BR2_INIT_SYSTEMD),\
>>               $($(PKG)_INSTALL_INIT_SYSTEMD))
>> @@ -312,6 +312,7 @@ $(2)_DEPENDENCIES ?= $(filter-out  host-toolchain $(1),\
>>  ifeq ($$($(2)_TYPE),target)
>>  $(2)_DEPENDENCIES += toolchain
>>  endif
>> +$(2)_BUILD_DEPENDENCIES              ?=
>>
>>  $(2)_INSTALL_STAGING         ?= NO
>>  $(2)_INSTALL_IMAGES          ?= NO
>> @@ -363,30 +364,29 @@ $(1)-install:           $(1)-install-staging $(1)-install-target $(1)-install-images
>>  endif
>>
>>  ifeq ($$($(2)_INSTALL_TARGET),YES)
>> -$(1)-install-target: $(1)-build \
>> -                     $$($(2)_TARGET_INSTALL_TARGET)
>> +$(1)-install-target: $$($(2)_TARGET_INSTALL_TARGET)
>>  else
>>  $(1)-install-target:
>>  endif
>>
>>  ifeq ($$($(2)_INSTALL_STAGING),YES)
>> -$(1)-install-staging:        $(1)-build \
>> -                     $$($(2)_TARGET_INSTALL_STAGING)
>> +$(1)-install-staging:        $$($(2)_TARGET_INSTALL_STAGING)
>>  else
>>  $(1)-install-staging:
>>  endif
>>
>>  ifeq ($$($(2)_INSTALL_IMAGES),YES)
>> -$(1)-install-images: $(1)-build \
>> -                     $$($(2)_TARGET_INSTALL_IMAGES)
>> +$(1)-install-images: $$($(2)_TARGET_INSTALL_IMAGES)
>>  else
>>  $(1)-install-images:
>>  endif
>>
>> -$(1)-install-host:      $(1)-build $$($(2)_TARGET_INSTALL_HOST)
>> +$(1)-install-host:      $$($(2)_TARGET_INSTALL_HOST)
>>
>> -$(1)-build:          $(1)-configure \
>> -                     $$($(2)_TARGET_BUILD)
>> +$$($(2)_TARGET_BUILD):       | $$($(2)_BUILD_DEPENDENCIES)
>> +$(1)-build:          $$($(2)_TARGET_BUILD)
>> +
>> +$(1)-configure:              $$($(2)_TARGET_CONFIGURE)
>>
>>  ifeq ($$($(2)_OVERRIDE_SRCDIR),)
>>  # In the normal case (no package override), the sequence of steps is
>> @@ -395,13 +395,11 @@ ifeq ($$($(2)_OVERRIDE_SRCDIR),)
>>  #  extract
>>  #  patch
>>  #  configure
>> -$(1)-configure:              $(1)-patch $(1)-depends \
>> -                     $$($(2)_TARGET_CONFIGURE)
>> +$$($(2)_TARGET_CONFIGURE):   | $$($(2)_DEPENDENCIES) $$($(2)_TARGET_PATCH)
>
> Why is $$($(2)_TARGET_PATCH) an order-only dependency? Why isn't the
> configure -> patch dependency handled like all the others, using stamp
> files dependencies?

I'm using an order-only dependency just to use a single line, i can
splt both rules:

$$($(2)_TARGET_CONFIGURE):   | $$($(2)_DEPENDENCIES)

ifeq
...
$$($(2)_TARGET_CONFIGURE):   $$($(2)_TARGET_PATCH)
...
else
...
$$($(2)_TARGET_CONFIGURE):   $$($(2)_TARGET_RSYNC)
...
endif

Do you like it?

If instead are you asking the reason because i have not used a %-rule,
is because that dependency is a conditional dependency that depends on
the value of $$($(2)_OVERRIDE_SRCDIR) and i don't know i way to use
that variable in a %-rule.
Do you have some suggestion about that?

> Note that I do understand the order-only dependency of
> $(2)_TARGET_CONFIGURE on $(2)_DEPENDENCIES, but not on
> $(2)_TARGET_PATCH.
>
>> -$(1)-patch:          $(1)-extract $$($(2)_TARGET_PATCH)
>> +$(1)-patch:          $$($(2)_TARGET_PATCH)
>>
>> -$(1)-extract:                $(1)-source \
>> -                     $$($(2)_TARGET_EXTRACT)
>> +$(1)-extract:                $$($(2)_TARGET_EXTRACT)
>>
>>  $(1)-depends:                $$($(2)_DEPENDENCIES)
>>
>> @@ -411,10 +409,9 @@ else
>>  #  source, by rsyncing
>>  #  depends
>>  #  configure
>> -$(1)-configure:              $(1)-depends \
>> -                     $$($(2)_TARGET_CONFIGURE)
>> +$$($(2)_TARGET_CONFIGURE):   | $$($(2)_DEPENDENCIES) $$($(2)_TARGET_RSYNC)
>>
>> -$(1)-depends:                $(1)-rsync $$($(2)_DEPENDENCIES)
>> +$(1)-depends:                $$($(2)_DEPENDENCIES)
>>
>>  $(1)-patch:          $(1)-rsync
>>  $(1)-extract:                $(1)-rsync
>> diff --git a/package/uclibc/uclibc.mk b/package/uclibc/uclibc.mk
>> index 181a772..8ae0e26 100644
>> --- a/package/uclibc/uclibc.mk
>> +++ b/package/uclibc/uclibc.mk
>> @@ -24,7 +24,8 @@ UCLIBC_DEPENDENCIES = host-gcc-initial linux-headers
>>
>>  # Before uClibc is built, we must have the second stage
>>  # cross-compiler, for some gcc versions, and when NPTL is used.
>> -uclibc-build: $(if $(BR2_TOOLCHAIN_NEEDS_THREE_STAGE_BUILD),host-gcc-intermediate)
>> +UCLIBC_BUILD_DEPENDENCIES = \
>> +     $(if $(BR2_TOOLCHAIN_NEEDS_THREE_STAGE_BUILD),host-gcc-intermediate)
>>
>>  # specifying UCLIBC_CONFIG_FILE on the command-line overrides the .config
>>  # setting.
>
> There is the same problem in package/glibc/glibc.mk.

Ok i will add the glibc package too.

Thanks and best regards
-- 
Fabio Porcedda

[Buildroot] [PATCH v4 3/3] package/Makefile.in: add a way to don't force jobs in sub-make

[Fabio Porcedda]

Hi Thomas,
thanks for reviewing.

On Thu, Sep 19, 2013 at 8:44 AM, Thomas De Schampheleire
<patrickdepinguin@gmail.com> wrote:
>
> Op 19-sep.-2013 08:35 schreef "Fabio Porcedda" <fabio.porcedda@gmail.com>
> het volgende:
>
>
>>
>> Hi Thomas and Clar?n,
>> thanks for reviewing.
>>
>> On Tue, Sep 17, 2013 at 8:24 PM, Ciar?n Rehill <cir.vfi@gmail.com> wrote:
>> > Maybe "add a way to prevent forcing of [parallel?] jobs in sub-make"?
>> >
>> > On Sep 17, 2013 7:18 PM, "Thomas Petazzoni"
>> > <thomas.petazzoni@free-electrons.com> wrote:
>> >>
>> >> Dear Fabio Porcedda,
>> >>
>> >> That's a minor nit, but "add a way to don't force jobs in sub-make"
>> >> isn't really correct english I blieve. "add away to not force the
>> >> number of jobs in sub-make" or something like that would be more
>> >> appropriate.
>>
>> What about a mix of both?
>> "add a way to prevent forcing the number of jobs in sub-make"
>>
>
> In fact, we don't add a way, since the user cannot choose to force or not.

IMHO the user can choose  by means of the "BR2_JLEVEL" variable, if
that variable contains a value buildroot will force the number of
jobs, if that variable is empty buildroot will not force the number of
jobs.

> So I'd suggest something like:
> Don't force the number of jobs...
> Or if you prefer:
> Prevent forcing...

Thanks and best regards
-- 
Fabio Porcedda

[Buildroot] [PATCH v4 3/3] package/Makefile.in: add a way to don't force jobs in sub-make

[Thomas De Schampheleire]

Hi Fabio,

On Thu, Sep 19, 2013 at 8:59 AM, Fabio Porcedda
<fabio.porcedda@gmail.com> wrote:
[..]
>> In fact, we don't add a way, since the user cannot choose to force or not.
>
> IMHO the user can choose  by means of the "BR2_JLEVEL" variable, if
> that variable contains a value buildroot will force the number of
> jobs, if that variable is empty buildroot will not force the number of
> jobs.

True, but BR2_JLEVEL was already there before your patch. What your
patch fixes is the situation where BR2_JLEVEL is empty, not 0, 1, 2,
3, ... as the original code expected. So, maybe a better title is:

package/Makefile.in: don't force parallel building when BR2_JLEVEL is empty

Best regards,
Thomas

[Buildroot] [PATCH v4 2/3] pkg-generic: fix rules for top-level parallel make

[Thomas Petazzoni]

Dear Fabio Porcedda,

On Thu, 19 Sep 2013 08:53:07 +0200, Fabio Porcedda wrote:

> > On Tue, 17 Sep 2013 09:59:12 +0200, Fabio Porcedda wrote:
> >> To be able to use top-level parallel make we must don't depend in a rule
> >
> > must don't -> should not
> 
> Maybe "must not" because is a requirement and not a suggestion?

I am not a native english speaker, but my vague memories from my
english lessons are that while "must" indicates an obligation, "must
not" does not indicate an interdiction, while "should not" does. Well,
a little bit of googling suggests I'm wrong. According to
http://www.englishpage.com/modals/must.html:

"""
"Must not" can be used to prohibit actions, but this sounds very
severe; speakers prefer to use softer modal verbs such as "should not"
or "ought not" to dissuade rather than prohibit. 
"""

So I believe you're right, we can keep "must not" (but not "must
don't"). Sorry for the noise.

> > Why is $$($(2)_TARGET_PATCH) an order-only dependency? Why isn't the
> > configure -> patch dependency handled like all the others, using stamp
> > files dependencies?
> 
> I'm using an order-only dependency just to use a single line, i can
> splt both rules:
> 
> $$($(2)_TARGET_CONFIGURE):   | $$($(2)_DEPENDENCIES)
> 
> ifeq
> ...
> $$($(2)_TARGET_CONFIGURE):   $$($(2)_TARGET_PATCH)
> ...
> else
> ...
> $$($(2)_TARGET_CONFIGURE):   $$($(2)_TARGET_RSYNC)
> ...
> endif
> 
> Do you like it?

I think it would be clearer. Also, it should be same for the other
dependencies between steps. Rather than putting them in the
$(BUILD_DIR)/%/.stamp_<something> rules, you could put them in the
$$($(2)_TARGET_<SOMETHING>) rules so that they are all at the same
place, no?

> If instead are you asking the reason because i have not used a %-rule,
> is because that dependency is a conditional dependency that depends on
> the value of $$($(2)_OVERRIDE_SRCDIR) and i don't know i way to use
> that variable in a %-rule.
> Do you have some suggestion about that?

See my suggestion above (if it works, of course).

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH v4 2/3] pkg-generic: fix rules for top-level parallel make

[Fabio Porcedda]

On Thu, Sep 19, 2013 at 9:39 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Fabio Porcedda,
>
> On Thu, 19 Sep 2013 08:53:07 +0200, Fabio Porcedda wrote:
>
>> > On Tue, 17 Sep 2013 09:59:12 +0200, Fabio Porcedda wrote:
>> >> To be able to use top-level parallel make we must don't depend in a rule
>> >
>> > must don't -> should not
>>
>> Maybe "must not" because is a requirement and not a suggestion?
>
> I am not a native english speaker, but my vague memories from my
> english lessons are that while "must" indicates an obligation, "must
> not" does not indicate an interdiction, while "should not" does. Well,
> a little bit of googling suggests I'm wrong. According to
> http://www.englishpage.com/modals/must.html:
>
> """
> "Must not" can be used to prohibit actions, but this sounds very
> severe; speakers prefer to use softer modal verbs such as "should not"
> or "ought not" to dissuade rather than prohibit.
> """
>
> So I believe you're right, we can keep "must not" (but not "must
> don't"). Sorry for the noise.

Ok

>> > Why is $$($(2)_TARGET_PATCH) an order-only dependency? Why isn't the
>> > configure -> patch dependency handled like all the others, using stamp
>> > files dependencies?
>>
>> I'm using an order-only dependency just to use a single line, i can
>> splt both rules:
>>
>> $$($(2)_TARGET_CONFIGURE):   | $$($(2)_DEPENDENCIES)
>>
>> ifeq
>> ...
>> $$($(2)_TARGET_CONFIGURE):   $$($(2)_TARGET_PATCH)
>> ...
>> else
>> ...
>> $$($(2)_TARGET_CONFIGURE):   $$($(2)_TARGET_RSYNC)
>> ...
>> endif
>>
>> Do you like it?
>
> I think it would be clearer. Also, it should be same for the other
> dependencies between steps. Rather than putting them in the
> $(BUILD_DIR)/%/.stamp_<something> rules, you could put them in the
> $$($(2)_TARGET_<SOMETHING>) rules so that they are all at the same
> place, no?

It's fine for me, in the previous version (v3) i was doing that, I
hope is fine even for Arnout.

>> If instead are you asking the reason because i have not used a %-rule,
>> is because that dependency is a conditional dependency that depends on
>> the value of $$($(2)_OVERRIDE_SRCDIR) and i don't know i way to use
>> that variable in a %-rule.
>> Do you have some suggestion about that?
>
> See my suggestion above (if it works, of course).

Ok

Thanks and best regards
-- 
Fabio Porcedda

[Buildroot] [PATCH v4 3/3] package/Makefile.in: add a way to don't force jobs in sub-make

[Fabio Porcedda]

On Thu, Sep 19, 2013 at 9:11 AM, Thomas De Schampheleire
<patrickdepinguin@gmail.com> wrote:
> Hi Fabio,
>
> On Thu, Sep 19, 2013 at 8:59 AM, Fabio Porcedda
> <fabio.porcedda@gmail.com> wrote:
> [..]
>>> In fact, we don't add a way, since the user cannot choose to force or not.
>>
>> IMHO the user can choose  by means of the "BR2_JLEVEL" variable, if
>> that variable contains a value buildroot will force the number of
>> jobs, if that variable is empty buildroot will not force the number of
>> jobs.
>
> True, but BR2_JLEVEL was already there before your patch. What your
> patch fixes is the situation where BR2_JLEVEL is empty, not 0, 1, 2,
> 3, ... as the original code expected. So, maybe a better title is:
>
> package/Makefile.in: don't force parallel building when BR2_JLEVEL is empty

Ok it's fine for me.

Thanks and best regards
-- 
Fabio Porcedda

[Buildroot] [PATCH v4 2/3] pkg-generic: fix rules for top-level parallel make

[Arnout Vandecappelle]

On 20/09/13 16:44, Fabio Porcedda wrote:
>>>> Why is $$($(2)_TARGET_PATCH) an order-only dependency? Why isn't the
>>>> >> >configure -> patch dependency handled like all the others, using stamp
>>>> >> >files dependencies?
>>> >>
>>> >>I'm using an order-only dependency just to use a single line, i can
>>> >>splt both rules:
>>> >>
>>> >>$$($(2)_TARGET_CONFIGURE):   | $$($(2)_DEPENDENCIES)
>>> >>
>>> >>ifeq
>>> >>...
>>> >>$$($(2)_TARGET_CONFIGURE):   $$($(2)_TARGET_PATCH)
>>> >>...
>>> >>else
>>> >>...
>>> >>$$($(2)_TARGET_CONFIGURE):   $$($(2)_TARGET_RSYNC)
>>> >>...
>>> >>endif
>>> >>
>>> >>Do you like it?
>> >
>> >I think it would be clearer. Also, it should be same for the other
>> >dependencies between steps. Rather than putting them in the
>> >$(BUILD_DIR)/%/.stamp_<something> rules, you could put them in the
>> >$$($(2)_TARGET_<SOMETHING>) rules so that they are all at the same
>> >place, no?
> It's fine for me, in the previous version (v3) i was doing that, I
> hope is fine even for Arnout.


  Ah yes, I didn't consider the rsync thing. In fact you're right, by 
putting the dependencies in the pattern rules you loose a lot of 
flexibility. So, back to the version you propose above!

  Regards,
  Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH v4 3/3] package/Makefile.in: add a way to don't force jobs in sub-make

[Fabio Porcedda]

On Fri, Sep 20, 2013 at 4:57 PM, Fabio Porcedda
<fabio.porcedda@gmail.com> wrote:
> On Thu, Sep 19, 2013 at 9:11 AM, Thomas De Schampheleire
> <patrickdepinguin@gmail.com> wrote:
>> Hi Fabio,
>>
>> On Thu, Sep 19, 2013 at 8:59 AM, Fabio Porcedda
>> <fabio.porcedda@gmail.com> wrote:
>> [..]
>>>> In fact, we don't add a way, since the user cannot choose to force or not.
>>>
>>> IMHO the user can choose  by means of the "BR2_JLEVEL" variable, if
>>> that variable contains a value buildroot will force the number of
>>> jobs, if that variable is empty buildroot will not force the number of
>>> jobs.
>>
>> True, but BR2_JLEVEL was already there before your patch. What your
>> patch fixes is the situation where BR2_JLEVEL is empty, not 0, 1, 2,
>> 3, ... as the original code expected. So, maybe a better title is:
>>
>> package/Makefile.in: don't force parallel building when BR2_JLEVEL is empty
>
> Ok it's fine for me.

Well the line it's too long (75 character), i will use:

package/Makefile.in: don't force jobs when BR2_JLEVEL is empty

Best regards
-- 
Fabio Porcedda