[llvm-dev] LLVM Releases: Upstream vs. Downstream / Distros

[Daniel Berlin via llvm-dev]

I'll bite:

Do you really believe you could ever get these folks to choose consistent
llvm versions anyway?

Or will you always have to do the work yourself anyway?

In my talks with a number of these projects, they pretty much don't care
what anyone else does, and plan to stick to their own import/etc schedules
no matter what LLVM does with stable releases :)

(For reference, Google *ships* the equivalent of about 13-16 linux
distributions in products, uses about 5-6x that internally, and we have a
single monolithic source repository for the most part.  I have the joy of
owning the third party software policies/etc for it, and so  end up
responsible for trying to deal with maintaining single versions of llvm for
tens to hundreds of packages).


On Thu, May 12, 2016 at 8:27 AM, Bernhard Rosenkränzer <
llvm-dev at lists.llvm.org> wrote:

> On 12 May 2016 at 16:56, Kristof Beyls <Kristof.Beyls at arm.com> wrote:
>
>> In my opinion, it would be better overall for the LLVM project if
>> top-of-trunk is
>> tested as much as possible, if testing resources are so scarce that a
>> choice
>> has to be made between testing top-of-trunk or testing a release branch.
>>
>
> I agree that trunk is more important, with both of my hats on.
>
> But releases are not completely irrelevant - one thing making them
> important is the fact that there's other projects out there using the LLVM
> libraries - and as a distro, we have to make sure they all work (so they
> agree on the same API), preferably without having to ship multiple versions
> of LLVM and preferably without having to patch external code too much to
> adjust to API changes.
>
> In OpenMandriva, we have to keep Mesa, creduce, emscripten and the
> LLVMified Qt moc working (list expected to grow -- ultimately we'd also
> like to use the system LLVM libraries for the swift compiler).
> In AOSP, RenderScript relies on the LLVM API, but there's nothing else
> using it, so there's currently no need to force a common version of the API
> between different projects there.
>
> ttyl
> bero
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160512/6d7287db/attachment.html>