<div dir="ltr">Ja som tiez za. Marek</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 18, 2019 at 4:42 PM Khem Raj <<a href="mailto:raj.khem@gmail.com">raj.khem@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Feb 18, 2019 at 7:15 AM Alexander Kanavin<br>
<<a href="mailto:alex.kanavin@gmail.com" target="_blank">alex.kanavin@gmail.com</a>> wrote:<br>
><br>
> On Mon, 18 Feb 2019 at 16:04, Khem Raj <<a href="mailto:raj.khem@gmail.com" target="_blank">raj.khem@gmail.com</a>> wrote:<br>
> > > There is now an official git repo for llvm, which also has version tags:<br>
> > ><br>
> > > <a href="https://github.com/llvm/llvm-project" rel="noreferrer" target="_blank">https://github.com/llvm/llvm-project</a><br>
> ><br>
> > yes there is and its intentional to use this mirror, since the<br>
> > llvm-project is a super repo and<br>
> > contains all llvm projects sources which is going to clone tonne<br>
> > unnecessary code.<br>
><br>
> More than half the commits are llvm's. (llvm-only mirror repo 175k,<br>
> llvm super-repo 310k)<br>
> So it adds to the clone, but not that much.<br>
<br>
I would have preferred to use mono repo and I have no problems using<br>
it since thats what we<br>
use in meta-clang as wella and it would make it simpler to reuse. but<br>
it can be a pain for other people.<br>
<br>
310k, I am not sure what is measured here. But here is the breakdown<br>
of sizes for information<br>
<br>
1.5G .<br>
676M ./.git<br>
16M ./lld<br>
51M ./libcxx<br>
3.5M ./libclc<br>
31M ./llgo<br>
32M ./polly<br>
395M ./llvm<br>
43M ./compiler-rt<br>
988K ./pstl<br>
116K ./debuginfo-tests<br>
720K ./libunwind<br>
13M ./clang-tools-extra<br>
7.3M ./openmp<br>
6.3M ./libcxxabi<br>
105M ./lldb<br>
352K ./parallel-libs<br>
155M ./clang<br>
<br>
<br>
><br>
> The point is something else:<br>
> - llvm-mirror is not an official repo, and may become stale/unmaintained<br>
> - llvm-mirror does not have version tags, so we can't trace commit ids<br>
> to the releases, or track upstream development with automatic tools<br>
><br>
> I think these two things outweigh the extra clone overhead.<br>
><br>
> > > I'll make a patch to switch over to that.<br>
> > ><br>
> > > Also note that final 8.0 is not yet out, so the recipe shouldn't make<br>
> > > it look like it is.<br>
> ><br>
> > This is intentional too.<br>
> > Its in rc stages and there are no specific chages espcially in<br>
> > versioning schemes<br>
> > which will mark it rc etc.<br>
><br>
> What I mean is there is no mention whatsoever that the recipe is<br>
> currently building a pre-release. It's not in PV, it's not anywhere in<br>
> the recipe. This can mislead people.<br>
<br>
Yes it can however, we know that when next release is cut out from<br>
master then we will be<br>
on a 8.x release.<br>
<br>
><br>
> Alex<br>
-- <br>
_______________________________________________<br>
Openembedded-core mailing list<br>
<a href="mailto:Openembedded-core@lists.openembedded.org" target="_blank">Openembedded-core@lists.openembedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/mailman/listinfo/openembedded-core</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">as simple and primitive as possible<br>-------------------------------------------------<br>Marek Belisko - OPEN-NANDRA<br>Freelance Developer<br><br>Ruska Nova Ves 219 | Presov, 08005 Slovak Republic<br>Tel: +421 915 052 184<br>skype: marekwhite<br>twitter: #opennandra<br>web: <a href="http://open-nandra.com" target="_blank">http://open-nandra.com</a></div>