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

Submitted by Thomas Petazzoni on Sept. 5, 2013, 9:27 p.m.

Details

Message ID 1378416469-17708-10-git-send-email-thomas.petazzoni@free-electrons.com
State Superseded
Headers show

Commit Message

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(+)

Comments

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 hide | download patch | download mbox

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)