Patchwork [RFCv1,09/11] package: add a <pkg>_SOURCE_ADDONS variable

login
register
mail settings
Submitter Thomas Petazzoni
Date Sept. 5, 2013, 9:27 p.m.
Message ID <1378416469-17708-10-git-send-email-thomas.petazzoni@free-electrons.com>
Download mbox | patch
Permalink /patch/272977/
State Superseded
Headers show

Comments

Thomas Petazzoni - Sept. 5, 2013, 9:27 p.m.
Converting the external toolchain logic into a package raises a very
special use case that wasn't handled by the package infrastructure:
the Blackfin toolchain is delivered as two tarballs instead of
one. Unfortunately <pkg>_SOURCE only allows to pass one tarball name.

However, we really want both tarballs to be known by the package
infrastructure, so that the normal 'source' and 'external-deps'
mechanism work fine.

In order to achieve this, we add a <pkg>_SOURCE_ADDONS variable, which
allows a package to list other stuff it would like to see downloaded,
but that are otherwise not used by the package infrastructure itself:
it is up to the package to do it by itself.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 package/pkg-generic.mk | 1 +
 1 file changed, 1 insertion(+)
Thomas De Schampheleire - Sept. 16, 2013, 1:39 p.m.
Hi Thomas,

On Thu, Sep 5, 2013 at 11:27 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Converting the external toolchain logic into a package raises a very
> special use case that wasn't handled by the package infrastructure:
> the Blackfin toolchain is delivered as two tarballs instead of
> one. Unfortunately <pkg>_SOURCE only allows to pass one tarball name.
>
> However, we really want both tarballs to be known by the package
> infrastructure, so that the normal 'source' and 'external-deps'
> mechanism work fine.
>
> In order to achieve this, we add a <pkg>_SOURCE_ADDONS variable, which
> allows a package to list other stuff it would like to see downloaded,
> but that are otherwise not used by the package infrastructure itself:
> it is up to the package to do it by itself.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
>  package/pkg-generic.mk | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/package/pkg-generic.mk b/package/pkg-generic.mk
> index b6f0bdd..2ce615f 100644
> --- a/package/pkg-generic.mk
> +++ b/package/pkg-generic.mk
> @@ -40,6 +40,7 @@ ifeq ($(DL_MODE),DOWNLOAD)
>         fi
>  endif
>         $(if $($(PKG)_SOURCE),$(call DOWNLOAD,$($(PKG)_SITE:/=)/$($(PKG)_SOURCE)))
> +       $(foreach p,$($(PKG)_SOURCE_ADDONS),$(call DOWNLOAD,$($(PKG)_SITE:/=)/$(p))$(sep))
>         $(foreach p,$($(PKG)_PATCH),$(call DOWNLOAD,$($(PKG)_SITE:/=)/$(p))$(sep))
>         $(foreach hook,$($(PKG)_POST_DOWNLOAD_HOOKS),$(call $(hook))$(sep))
>  ifeq ($(DL_MODE),DOWNLOAD)
> --

What about allowing FOO_SOURCE to contain multiple words directly, and
thus not introducing a new variable? The package infrastructure can
download each word of FOO_SOURCE, but only extract (and otherwise use)
the first one. Any subsequent word has to be handled by the package
itself.

Best regards,
Thomas
Thomas Petazzoni - Sept. 16, 2013, 6:31 p.m.
Dear Thomas De Schampheleire,

On Mon, 16 Sep 2013 15:39:22 +0200, Thomas De Schampheleire wrote:

> What about allowing FOO_SOURCE to contain multiple words directly, and
> thus not introducing a new variable? The package infrastructure can
> download each word of FOO_SOURCE, but only extract (and otherwise use)
> the first one. Any subsequent word has to be handled by the package
> itself.

The problem is that the default extract step needs to know what to do.
And what it does today is that it extracts the tarball whose name is
given in FOO_SOURCE. If we put several words in FOO_SOURCE, then what
should be the semantic of the default extract commands? Extract the
first one? All of them?

That's why I've decided to go with another variable, which really means
"I want this stuff to be downloaded, but don't do anything with it, the
package recipe will take care of it".

Of course, I'm open to changing the semantic of FOO_SOURCE instead, we
would just need to define what this new semantic should be.

Thanks!

Thomas
Arnout Vandecappelle - Sept. 16, 2013, 7:20 p.m.
On 16/09/13 20:31, Thomas Petazzoni wrote:
> Dear Thomas De Schampheleire,
>
> On Mon, 16 Sep 2013 15:39:22 +0200, Thomas De Schampheleire wrote:
>
>> What about allowing FOO_SOURCE to contain multiple words directly, and
>> thus not introducing a new variable? The package infrastructure can
>> download each word of FOO_SOURCE, but only extract (and otherwise use)
>> the first one. Any subsequent word has to be handled by the package
>> itself.
>
> The problem is that the default extract step needs to know what to do.
> And what it does today is that it extracts the tarball whose name is
> given in FOO_SOURCE. If we put several words in FOO_SOURCE, then what
> should be the semantic of the default extract commands? Extract the
> first one? All of them?
>
> That's why I've decided to go with another variable, which really means
> "I want this stuff to be downloaded, but don't do anything with it, the
> package recipe will take care of it".
>
> Of course, I'm open to changing the semantic of FOO_SOURCE instead, we
> would just need to define what this new semantic should be.

  I'm more in favour of the <pkg>_SOURCE_ADDONS proposal. I think having 
multiple _SOURCE files would be confusing.


  Regards,
  Arnout
Thomas De Schampheleire - Sept. 17, 2013, 7:21 a.m.
Thomas, Arnout,

On Mon, Sep 16, 2013 at 9:20 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
> On 16/09/13 20:31, Thomas Petazzoni wrote:
>>
>> Dear Thomas De Schampheleire,
>>
>> On Mon, 16 Sep 2013 15:39:22 +0200, Thomas De Schampheleire wrote:
>>
>>> What about allowing FOO_SOURCE to contain multiple words directly, and
>>> thus not introducing a new variable? The package infrastructure can
>>> download each word of FOO_SOURCE, but only extract (and otherwise use)
>>> the first one. Any subsequent word has to be handled by the package
>>> itself.
>>
>>
>> The problem is that the default extract step needs to know what to do.
>> And what it does today is that it extracts the tarball whose name is
>> given in FOO_SOURCE. If we put several words in FOO_SOURCE, then what
>> should be the semantic of the default extract commands? Extract the
>> first one? All of them?
>>
>> That's why I've decided to go with another variable, which really means
>> "I want this stuff to be downloaded, but don't do anything with it, the
>> package recipe will take care of it".
>>
>> Of course, I'm open to changing the semantic of FOO_SOURCE instead, we
>> would just need to define what this new semantic should be.
>
>
>  I'm more in favour of the <pkg>_SOURCE_ADDONS proposal. I think having
> multiple _SOURCE files would be confusing.

Ok, fair enough.
I think you should add this to the documentation, then.

Best regards,
Thomas
Luca Ceresoli - Sept. 27, 2013, 2:27 p.m.
Thomas De Schampheleire wrote:
> Thomas, Arnout,
>
> On Mon, Sep 16, 2013 at 9:20 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
>> On 16/09/13 20:31, Thomas Petazzoni wrote:
>>> Dear Thomas De Schampheleire,
>>>
>>> On Mon, 16 Sep 2013 15:39:22 +0200, Thomas De Schampheleire wrote:
>>>
>>>> What about allowing FOO_SOURCE to contain multiple words directly, and
>>>> thus not introducing a new variable? The package infrastructure can
>>>> download each word of FOO_SOURCE, but only extract (and otherwise use)
>>>> the first one. Any subsequent word has to be handled by the package
>>>> itself.
>>>
>>> The problem is that the default extract step needs to know what to do.
>>> And what it does today is that it extracts the tarball whose name is
>>> given in FOO_SOURCE. If we put several words in FOO_SOURCE, then what
>>> should be the semantic of the default extract commands? Extract the
>>> first one? All of them?
>>>
>>> That's why I've decided to go with another variable, which really means
>>> "I want this stuff to be downloaded, but don't do anything with it, the
>>> package recipe will take care of it".
>>>
>>> Of course, I'm open to changing the semantic of FOO_SOURCE instead, we
>>> would just need to define what this new semantic should be.
>>
>>   I'm more in favour of the <pkg>_SOURCE_ADDONS proposal. I think having
>> multiple _SOURCE files would be confusing.
> Ok, fair enough.
> I think you should add this to the documentation, then.

I also think keeping things separate is the best option to avoid confusion.
But to make it even more clear, I would name the variable _EXTRA_DOWNLOADS.

Patch

diff --git a/package/pkg-generic.mk b/package/pkg-generic.mk
index b6f0bdd..2ce615f 100644
--- a/package/pkg-generic.mk
+++ b/package/pkg-generic.mk
@@ -40,6 +40,7 @@  ifeq ($(DL_MODE),DOWNLOAD)
 	fi
 endif
 	$(if $($(PKG)_SOURCE),$(call DOWNLOAD,$($(PKG)_SITE:/=)/$($(PKG)_SOURCE)))
+	$(foreach p,$($(PKG)_SOURCE_ADDONS),$(call DOWNLOAD,$($(PKG)_SITE:/=)/$(p))$(sep))
 	$(foreach p,$($(PKG)_PATCH),$(call DOWNLOAD,$($(PKG)_SITE:/=)/$(p))$(sep))
 	$(foreach hook,$($(PKG)_POST_DOWNLOAD_HOOKS),$(call $(hook))$(sep))
 ifeq ($(DL_MODE),DOWNLOAD)