llvm dev - May 2016 - LLVM Releases: Upstream vs. Downstream / Distros

On Thu, 12 May 2016 16:40:44 +0100
David Chisnall via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
> 
> The end result is that shortly after a release (sometimes every alternate
release) is branched a load of downstream projects update to the new APIs, test
things, and find a bunch of regressions that have been sitting in the tree for
months.  We then have to scrabble to bisect and try to track them down.
> 
> TL;DR version: If we want downstream people to test ToT, then we need to
make updating LLVM library consumers to ToT far less painful than it is now.
+1 to this.  As a developer of llvmlite and numba, it would be
counter-productive for me to try to follow the LLVM ToT, as opposed to
migrate after a X.Y.1 release as we currently do.

Regards

Antoine.

On 12 May 2016 at 16:47, Antoine Pitrou via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> +1 to this.  As a developer of llvmlite and numba, it would be
> counter-productive for me to try to follow the LLVM ToT, as opposed to
> migrate after a X.Y.1 release as we currently do.
There's also how many APIs do we create packages for?

If your projects use 3.5, some others use 3.6, etc. then distros need
to keep packages for *all* of them and *also* have Clang packages,
maybe more than one. This can get nasty...

I'm not sure how to solve that... :(

--renato

On 12 May 2016, at 16:53, Renato Golin via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> On 12 May 2016 at 16:47, Antoine Pitrou via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> +1 to this.  As a developer of llvmlite and numba, it would be
>> counter-productive for me to try to follow the LLVM ToT, as opposed to
>> migrate after a X.Y.1 release as we currently do.
> 
> There's also how many APIs do we create packages for?
> 
> If your projects use 3.5, some others use 3.6, etc. then distros need
> to keep packages for *all* of them and *also* have Clang packages,
> maybe more than one. This can get nasty...
> 
> I'm not sure how to solve that... :(
With my downstream hat on, this isn’t really a problem for FreeBSD in most
cases.  We have ports for LLVM 3.3 and upwards (3.2 earlier have no remaining
users and have been removed).  Aside from disk space usage, it’s only a problem
when we find a program that links to two things that link to different versions
of LLVM, which is fairly rare.  We could fix this fairly trivially by sticking
everything in headers in an llvm_{major}_{minor} namespace just as libc++ puts
everything in a __v1 namespace.

As long as we have only a handful of different releases to support, it’s fine. 
The problem only comes when we have a few hundred API-incompatible versions in
between X.Y and X.Y+1 (I don’t even care about ABI compatibility with this hat
on, as we recompile the entire ports collection every time that we generate a
new package set).

David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3719 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160512/00e1e02e/attachment.bin>