[Buildroot] [PATCH v2 2/3] package/cal3d: new package
Peter Korsgaard
peter at korsgaard.com
Sun Dec 20 21:52:20 UTC 2015
>>>>> "Yann" == Yann E MORIN <yann.morin.1998 at 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?
--
Venlig hilsen,
Peter Korsgaard
More information about the buildroot
mailing list