[v2,2/3] package/cal3d: new package

This package only provides a git submodule for the vsxu package.

Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
---
v2: no changes

 package/Config.in       |  1 +
 package/cal3d/Config.in |  6 ++++++
 package/cal3d/cal3d.mk  | 10 ++++++++++
 3 files changed, 17 insertions(+)
 create mode 100644 package/cal3d/Config.in
 create mode 100644 package/cal3d/cal3d.mk

Hello,

On Sat,  7 Nov 2015 17:50:52 +0100, Bernd Kuhls wrote:
> This package only provides a git submodule for the vsxu package.
> 
> Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>

I don't really like the interaction between this package and the vsxu
package, but I don't really have a better proposal to be honest.

Yann, Peter, Arnout, do you have some suggestions on how to handle such
git submodule cases?

Thanks,

Thomas

Thomas, All,

On 2015-12-19 15:00 +0100, Thomas Petazzoni spake thusly:
> On Sat,  7 Nov 2015 17:50:52 +0100, Bernd Kuhls wrote:
> > This package only provides a git submodule for the vsxu package.
> > 
> > Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
> 
> I don't really like the interaction between this package and the vsxu
> package, but I don't really have a better proposal to be honest.
> 
> Yann, Peter, Arnout, do you have some suggestions on how to handle such
> git submodule cases?

I really don't know what to do with git-submodules.

But in this precise case, I would:
  - dump the cal3d package
  - add a post-download hook (or an extra-download URL) to vsxu to also
    download cal3d
  - add a post-extract hook to vsxu to also extract cal3d in the correct
    location.

Then, when/if cal3d is later used by other packages, we can revisit the
situation.

Otherwise, for proper git-submodule handling, we would have to do
(roughly):

    git clone blabla pkg-version
    cd pkg-version
    git checkout pkg-version
    git submodule update --init --recursive
    find . -name .git -exec rm -rf {} +
    cd ..
    tar czf DL_DIR/pkg-version.tar.gz pkg-version/

This is not very complex, but is stil la significant change from our
current git wrapper.

And then, what about svn externals? About Hg subrepos? Does bzr also
have such a thing?

Note that I would not really mind doing such a change. But is it worth
it, given that we currently have only one package that needs submodules?
Or do we have others for which we had to "deal with it" in a crude way?

Regards,
Yann E. MORIN.

Yann,

On Sat, 19 Dec 2015 15:25:09 +0100, Yann E. MORIN wrote:

> But in this precise case, I would:
>   - dump the cal3d package
>   - add a post-download hook (or an extra-download URL) to vsxu to also
>     download cal3d

A post-download hook wouldn't play well with "make source", "make
legal-info" and all. We have to take this into account. But an
EXTRA_DOWNLOADS should work fine.

>   - add a post-extract hook to vsxu to also extract cal3d in the correct
>     location.

Could be a solution, I'll try this.

> Otherwise, for proper git-submodule handling, we would have to do
> (roughly):
> 
>     git clone blabla pkg-version
>     cd pkg-version
>     git checkout pkg-version
>     git submodule update --init --recursive
>     find . -name .git -exec rm -rf {} +
>     cd ..
>     tar czf DL_DIR/pkg-version.tar.gz pkg-version/
> 
> This is not very complex, but is stil la significant change from our
> current git wrapper.
> 
> And then, what about svn externals? About Hg subrepos? Does bzr also
> have such a thing?
> 
> Note that I would not really mind doing such a change. But is it worth
> it, given that we currently have only one package that needs submodules?
> Or do we have others for which we had to "deal with it" in a crude way?

I don't want to go down this route for the moment, I'd prefer to see
how many of these git submodule users we have.

Thomas

On 19-12-15 15:00, Thomas Petazzoni wrote:
> Hello,
> 
> On Sat,  7 Nov 2015 17:50:52 +0100, Bernd Kuhls wrote:
>> This package only provides a git submodule for the vsxu package.
>>
>> Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
> 
> I don't really like the interaction between this package and the vsxu
> package, but I don't really have a better proposal to be honest.
> 
> Yann, Peter, Arnout, do you have some suggestions on how to handle such
> git submodule cases?

 Good that Bernd put that reference to my mail of two years ago [1]. When I read
that again I first thought that I would retract my statements from back then,
but in fact it still makes sense.

 There are basically two ways that we can consider such packages.

 The first way is to say it is a bundled package, in other words we download and
extract the submodule as part of the master. We have a precendent for this:
perl-cross (though there it's a bit the other way round, the principle is the
same). I described this approach as the first option for [1].

 The second way is to say that it is a separate package and we basically
unbundle it. Since the package itself doesn't support that, we have to do some
hacks to make it work, just like any distro has to make hacks to unbundle stuff.

 The second way is hackish because:
- we're instantiating the submodule in a different way than the package expects
it (as a symlink rather as a subtree);
- we're referring to the source of one package from another package.

 This last bit, however, is something we do all the time with LINUX_DIR, so
maybe it's not that much of a hack after all.

 The second way tends to be a bit less verbose too, because we can use a lot of
infrastructure that just doesn't exist to support the sub-package approach. But
it's not as bad anymore as when I wrote [1], because now we can use
_EXTRA_DOWNLOADS at least, so we just need to add a post-extract hook. So the
difference is just 2-3 lines.

 I have a slight preference for the first approach, but I would be fine with the
second approach (which Bernd chose here) as well. Though I do have a few
comments on that, which I'll state in the patch itself.

 Regards,
 Arnout


[1] http://lists.busybox.net/pipermail/buildroot/2013-March/069971.html

On 07-11-15 17:50, Bernd Kuhls wrote:
> This package only provides a git submodule for the vsxu package.
> 
> Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
> ---
> v2: no changes
> 
>  package/Config.in       |  1 +
>  package/cal3d/Config.in |  6 ++++++
>  package/cal3d/cal3d.mk  | 10 ++++++++++
>  3 files changed, 17 insertions(+)
>  create mode 100644 package/cal3d/Config.in
>  create mode 100644 package/cal3d/cal3d.mk
> 
> diff --git a/package/Config.in b/package/Config.in
> index d278e64..eb601e8 100644
> --- a/package/Config.in
> +++ b/package/Config.in
> @@ -227,6 +227,7 @@ comment "Graphic applications"
>  	source "package/rrdtool/Config.in"
>  
>  comment "Graphic libraries"
> +	source "package/cal3d/Config.in"
>  	source "package/cegui06/Config.in"
>  	source "package/directfb/Config.in"
>  	source "package/directfb-examples/Config.in"
> diff --git a/package/cal3d/Config.in b/package/cal3d/Config.in
> new file mode 100644
> index 0000000..231d905
> --- /dev/null
> +++ b/package/cal3d/Config.in
> @@ -0,0 +1,6 @@
> +config BR2_PACKAGE_CAL3D
> +	help
> +	  Cal3D is a skeletal based character animation library.
> +	  This package provides a git submodule for the vsxu package.
> +
> +	  https://github.com/vovoid/cal3d

 If you take this approach (which, given Yann's and Thomas's feedback, you
probably won't), then I don't think you should add a Config.in file. It makes no
sense at all for the user to be able to select this package, because it doesn't
install anything in staging or target so it cannot be used.

 Regards,
 Arnout

> diff --git a/package/cal3d/cal3d.mk b/package/cal3d/cal3d.mk
> new file mode 100644
> index 0000000..0a7813f
> --- /dev/null
> +++ b/package/cal3d/cal3d.mk
> @@ -0,0 +1,10 @@
> +################################################################################
> +#
> +# cal3d
> +#
> +################################################################################
> +
> +CAL3D_VERSION = 0f640189eec913973c64db3bc1c1685554cb7202
> +CAL3D_SITE = $(call github,vovoid,cal3d,$(CAL3D_VERSION))
> +
> +$(eval $(generic-package))
>

On 19-12-15 15:25, Yann E. MORIN wrote:
> Thomas, All,
> 
> On 2015-12-19 15:00 +0100, Thomas Petazzoni spake thusly:
>> On Sat,  7 Nov 2015 17:50:52 +0100, Bernd Kuhls wrote:
>>> This package only provides a git submodule for the vsxu package.
>>>
>>> Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
>>
>> I don't really like the interaction between this package and the vsxu
>> package, but I don't really have a better proposal to be honest.
>>
>> Yann, Peter, Arnout, do you have some suggestions on how to handle such
>> git submodule cases?
[snip]
> Otherwise, for proper git-submodule handling, we would have to do
> (roughly):
> 
>     git clone blabla pkg-version
>     cd pkg-version
>     git checkout pkg-version
>     git submodule update --init --recursive
>     find . -name .git -exec rm -rf {} +
>     cd ..
>     tar czf DL_DIR/pkg-version.tar.gz pkg-version/

 Err, anything wrong with just adding --recursive to the clone command? Or is
that a recent addition? Oh, but git archive still wouldn't add it of course.

 But anyway, in this particular case we're using a github tarball download so it
wouldn't help. Unless it would switch to git download instead.

> 
> This is not very complex, but is stil la significant change from our
> current git wrapper.
> 
> And then, what about svn externals? About Hg subrepos? Does bzr also
> have such a thing?
> 
> Note that I would not really mind doing such a change. But is it worth
> it, given that we currently have only one package that needs submodules?
> Or do we have others for which we had to "deal with it" in a crude way?

 I'm pretty sure there aren't any other packages that need it.

 Regards,
 Arnout

> 
> Regards,
> Yann E. MORIN.
>

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

Hi,

 > I really don't know what to do with git-submodules.

 > But in this precise case, I would:
 >   - dump the cal3d package
 >   - add a post-download hook (or an extra-download URL) to vsxu to also
 >     download cal3d
 >   - add a post-extract hook to vsxu to also extract cal3d in the correct
 >     location.

 > Then, when/if cal3d is later used by other packages, we can revisit the
 > situation.

Yes, I think that makes sense as well.


 > Otherwise, for proper git-submodule handling, we would have to do
 > (roughly):

 >     git clone blabla pkg-version
 >     cd pkg-version
 >     git checkout pkg-version
 >     git submodule update --init --recursive
 >     find . -name .git -exec rm -rf {} +
 >     cd ..
 >     tar czf DL_DIR/pkg-version.tar.gz pkg-version/

 > This is not very complex, but is stil la significant change from our
 > current git wrapper.

Yes, I would prefer if we wouldn't have to do that.

 > And then, what about svn externals? About Hg subrepos? Does bzr also
 > have such a thing?

For svn we create the tarball ourselves, so I believe externals should
work.

I'm not really familiar with hg, but I guess it behaves like git.


 > Note that I would not really mind doing such a change. But is it worth
 > it, given that we currently have only one package that needs submodules?
 > Or do we have others for which we had to "deal with it" in a crude way?

I had a local package at work that originally used git submodules, and
the gstreamer packages use a submodule for "common stuff", so we would
have the issue if we ever moved to getting these from git.

So I think there is a potential use case for it, but it is really quite
a pity that they aren't handled natively by git archive.

Perhaps we should bring it up with the git developers?