[llvm-dev] LLVM Releases: Upstream vs. Downstream / Distros
Daniel Berlin via llvm-dev
llvm-dev at lists.llvm.org
Thu May 12 09:07:10 PDT 2016
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
>> 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.
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev