On Fri, Sep 14, 2012 at 8:25 AM, Otavio Salvador
ota...@ossystems.com.br wrote:
On Fri, Sep 14, 2012 at 10:23 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Fri, 2012-09-14 at 09:36 -0300, Otavio Salvador wrote:
On Fri, Sep 14, 2012 at 8:58 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Thu, 2012-09-13 at 07:22 -0700, Chris Larson wrote:
On Thu, Sep 13, 2012 at 6:06 AM, Otavio Salvador
ota...@ossystems.com.br wrote:
On Thu, Sep 13, 2012 at 9:19 AM, Björn Stenberg b...@enea.com wrote:
Khem Raj wrote:
I agree but then 1.7 GB is noticeably huge too and it will only
become
larger in future so I don't think fetching from git will be a good
solution
for gcc ever.
Can we use shallow clones? A quick test of gcc-4.7 gave me a 308 MB
tar.gz when cloned with --depth 1.
I did not check if the fetcher has this support but it would be a
nice solution.
Shallow clones won't be able to support SRCREV properly, as you can
only clone shallowly from HEAD, not from an arbitrary point in
history, AFAIK.
Right, shallow clones are a can of worms from a variety of angles.
My current thinking is a ;allowsinglerev=1 parameter to the git fetcher
which:
a) Generates tarballs of single git revisions if tarball generation is
turned on
b) Searches for single revision tarballs before trying the main checkout
approach.
This would mean that WORKDIR may or may not have a .git directory for
any SRC_URI marked with this. I think we should all be able to live with
that and it shouldn't break too much?
We'll end with multiple tarballs, aren't we?
Yes. I'm not seeing that as a big problem for most of the usecases where
we'd use this feature. You could skip shipping the big tarball of the
whole repo at distribution time.
By the way, there're any tool to clean the repo? (as we do for sstate-cache)?
scripts/clean-workdir cleans tmp/ - not sure about downloads
-M
--
Otavio Salvador O.S. Systems
E-mail: ota...@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
___
bitbake-devel mailing list
bitbake-de...@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/bitbake-devel
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
