[Buildroot] [git commit master 1/1] Makefile.package.in: allow packages to override download step

[Buildroot] [git commit master 1/1] Makefile.package.in: allow packages to override download step

[Peter Korsgaard]

commit: http://git.buildroot.net/buildroot/commit/?id=48cf66f1a2e2c501abeee98b7a2268b0d6d2010d
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master

E.G. for checkout from version control instead.

Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
 package/Makefile.package.in |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/package/Makefile.package.in b/package/Makefile.package.in
index 16ce16a..c476de9 100644
--- a/package/Makefile.package.in
+++ b/package/Makefile.package.in
@@ -292,7 +292,7 @@ $(2)_TARGET_BUILD =		$$($(2)_DIR)/.stamp_built
 $(2)_TARGET_CONFIGURE =		$$($(2)_DIR)/.stamp_configured
 $(2)_TARGET_PATCH =		$$($(2)_DIR)/.stamp_patched
 $(2)_TARGET_EXTRACT =		$$($(2)_DIR)/.stamp_extracted
-$(2)_TARGET_SOURCE =		$$($(2)_DIR)/.stamp_downloaded
+$(2)_TARGET_SOURCE ?=		$$($(2)_DIR)/.stamp_downloaded
 $(2)_TARGET_UNINSTALL =		$$($(2)_DIR)/.stamp_uninstalled
 $(2)_TARGET_CLEAN =		$$($(2)_DIR)/.stamp_cleaned
 $(2)_TARGET_DIRCLEAN =		$$($(2)_DIR)/.stamp_dircleaned
-- 
1.7.1

[Buildroot] [git commit master 1/1] Makefile.package.in: allow packages to override download step

[Thomas Petazzoni]

Hello,

On Thu, 1 Jul 2010 17:33:29 +0200
Peter Korsgaard <jacmet@sunsite.dk> wrote:

> diff --git a/package/Makefile.package.in b/package/Makefile.package.in
> index 16ce16a..c476de9 100644
> --- a/package/Makefile.package.in
> +++ b/package/Makefile.package.in
> @@ -292,7 +292,7 @@ $(2)_TARGET_BUILD =
> $$($(2)_DIR)/.stamp_built $(2)_TARGET_CONFIGURE =
> $$($(2)_DIR)/.stamp_configured $(2)_TARGET_PATCH =
> $$($(2)_DIR)/.stamp_patched $(2)_TARGET_EXTRACT =
> $$($(2)_DIR)/.stamp_extracted -$(2)_TARGET_SOURCE =
> $$($(2)_DIR)/.stamp_downloaded +$(2)_TARGET_SOURCE ?=
> $$($(2)_DIR)/.stamp_downloaded $(2)_TARGET_UNINSTALL =
> $$($(2)_DIR)/.stamp_uninstalled $(2)_TARGET_CLEAN =
> $$($(2)_DIR)/.stamp_cleaned $(2)_TARGET_DIRCLEAN =
> $$($(2)_DIR)/.stamp_dircleaned

As said on IRC, I'm sorry but I don't think I really like this.

We already have a mechanism to override steps in Makefile.autotools.in.
I'd prefer to see if we can rely on a similar mechanism rather than
doing this.

In the future, is it possible to discuss such infrastructure changes on
the list beforehand ?

Thanks,

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

[Buildroot] [git commit master 1/1] Makefile.package.in: allow packages to override download step

[Luca Ceresoli]

Thomas Petazzoni ha scritto:
> Hello,
>
> On Thu, 1 Jul 2010 17:33:29 +0200
> Peter Korsgaard <jacmet@sunsite.dk> wrote:
>
>   
>> diff --git a/package/Makefile.package.in b/package/Makefile.package.in
>> index 16ce16a..c476de9 100644
>> --- a/package/Makefile.package.in
>> +++ b/package/Makefile.package.in
>> @@ -292,7 +292,7 @@ $(2)_TARGET_BUILD =
>> $$($(2)_DIR)/.stamp_built $(2)_TARGET_CONFIGURE =
>> $$($(2)_DIR)/.stamp_configured $(2)_TARGET_PATCH =
>> $$($(2)_DIR)/.stamp_patched $(2)_TARGET_EXTRACT =
>> $$($(2)_DIR)/.stamp_extracted -$(2)_TARGET_SOURCE =
>> $$($(2)_DIR)/.stamp_downloaded +$(2)_TARGET_SOURCE ?=
>> $$($(2)_DIR)/.stamp_downloaded $(2)_TARGET_UNINSTALL =
>> $$($(2)_DIR)/.stamp_uninstalled $(2)_TARGET_CLEAN =
>> $$($(2)_DIR)/.stamp_cleaned $(2)_TARGET_DIRCLEAN =
>> $$($(2)_DIR)/.stamp_dircleaned
>>     
>
> As said on IRC, I'm sorry but I don't think I really like this.
>
> We already have a mechanism to override steps in Makefile.autotools.in.
> I'd prefer to see if we can rely on a similar mechanism rather than
> doing this.
>   
It's a good feature to have, but I agree with Thomas about the way to 
implement it. As I proposed in the discussion about "Getting package 
sources from git/svn/bzr", I'd rather make the DOWNLOAD command 
overridable in package/Makefile.package.in, like this:

@@ -118,19 +118,19 @@
 # Retrieve the archive
 $(BUILD_DIR)/%/.stamp_downloaded:
 # support make source-check/external-deps
 ifeq ($(SPIDER),)
 # Only show the download message if it isn't already downloaded
 	$(Q)(test -e $(DL_DIR)/$($(PKG)_SOURCE) && \
 		(test -z $($(PKG)_PATCH) || test -e $(DL_DIR)$($(PKG)_PATCH))) || \
 		$(call MESSAGE,"Downloading")
 endif
-	$(call DOWNLOAD,$($(PKG)_SITE),$($(PKG)_SOURCE))
+	$($(PKG)_DOWNLOAD_CMDS)
 	$(if $($(PKG)_PATCH),$(call DOWNLOAD,$($(PKG)_SITE),$($(PKG)_PATCH)))


where of course $(PKG)_DOWNLOAD_CMDS would default to $(call DOWNLOAD,...).

Would such a patch be applied, if I wrote one?


Luca

[Buildroot] [git commit master 1/1] Makefile.package.in: allow packages to override download step

[Thomas Petazzoni]

On Wed, 07 Jul 2010 22:21:59 +0200
Luca Ceresoli <luca@lucaceresoli.net> wrote:

> It's a good feature to have, but I agree with Thomas about the way to 
> implement it. As I proposed in the discussion about "Getting package 
> sources from git/svn/bzr", I'd rather make the DOWNLOAD command 
> overridable in package/Makefile.package.in, like this:
> 
> @@ -118,19 +118,19 @@
>  # Retrieve the archive
>  $(BUILD_DIR)/%/.stamp_downloaded:
>  # support make source-check/external-deps
>  ifeq ($(SPIDER),)
>  # Only show the download message if it isn't already downloaded
>  	$(Q)(test -e $(DL_DIR)/$($(PKG)_SOURCE) && \
>  		(test -z $($(PKG)_PATCH) || test -e $(DL_DIR)$($(PKG)_PATCH))) || \
>  		$(call MESSAGE,"Downloading")
>  endif
> -	$(call DOWNLOAD,$($(PKG)_SITE),$($(PKG)_SOURCE))
> +	$($(PKG)_DOWNLOAD_CMDS)
>  	$(if $($(PKG)_PATCH),$(call DOWNLOAD,$($(PKG)_SITE),$($(PKG)_PATCH)))
> 
> 
> where of course $(PKG)_DOWNLOAD_CMDS would default to $(call DOWNLOAD,...).
> 
> Would such a patch be applied, if I wrote one?

There's another approach currently being developed: integrate support
for Git/SVN directly into the infrastructure. I hope to see the patch
for this coming pretty soon.

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

[Buildroot] [git commit master 1/1] Makefile.package.in: allow packages to override download step

[Luca Ceresoli]

Thomas Petazzoni wrote:
> On Wed, 07 Jul 2010 22:21:59 +0200
> Luca Ceresoli <luca@lucaceresoli.net> wrote:
> 
> > It's a good feature to have, but I agree with Thomas about the way to 
> > implement it. As I proposed in the discussion about "Getting package 
> > sources from git/svn/bzr", I'd rather make the DOWNLOAD command 
> > overridable in package/Makefile.package.in, like this:
> > 
> > @@ -118,19 +118,19 @@
> >  # Retrieve the archive
> >  $(BUILD_DIR)/%/.stamp_downloaded:
> >  # support make source-check/external-deps
> >  ifeq ($(SPIDER),)
> >  # Only show the download message if it isn't already downloaded
> >  	$(Q)(test -e $(DL_DIR)/$($(PKG)_SOURCE) && \
> >  		(test -z $($(PKG)_PATCH) || test -e $(DL_DIR)$($(PKG)_PATCH))) || \
> >  		$(call MESSAGE,"Downloading")
> >  endif
> > -	$(call DOWNLOAD,$($(PKG)_SITE),$($(PKG)_SOURCE))
> > +	$($(PKG)_DOWNLOAD_CMDS)
> >  	$(if $($(PKG)_PATCH),$(call DOWNLOAD,$($(PKG)_SITE),$($(PKG)_PATCH)))
> > 
> > 
> > where of course $(PKG)_DOWNLOAD_CMDS would default to $(call DOWNLOAD,...).
> > 
> > Would such a patch be applied, if I wrote one?
> 
> There's another approach currently being developed: integrate support
> for Git/SVN directly into the infrastructure. I hope to see the patch
> for this coming pretty soon.

Sure I know, as I fired up that thread. But I wonder who's working on it.
If you mean me, I haven't had the time to work on this yet, and might never
have time to clean it up for upstream. If others are, it would be good to
know in order to coordinate instead of duplicating work.

Still, I would like to have a customizable $(PKG)_DOWNLOAD_CMDS anyway.

It would be a precious hook for those, such as enterprise developers, in
the need to use strange download actions that are not in BR, and may even
never be accepted for upstream integration.
This way, all of the non-upstream code would reside in the package,
well isolated from the rest.

Luca