| Message ID | 1378416469-17708-10-git-send-email-thomas.petazzoni@free-electrons.com |
|---|---|
| State | Superseded |
| Headers | show |
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
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
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, 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
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.
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)
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(+)