Re: llvm update to 13.0.0

[Thomas Klausner <wiz%NetBSD.org@localhost>]

Hi Greg!

On Sun, Nov 21, 2021 at 10:33:01AM -0500, Greg Troxel wrote:
> Thomas Klausner <wiz%NetBSD.org@localhost> writes:
> 
> > Attached you can find an update for the llvm-related packages to the
> > current release, 13.0.0.
> >
> > I've tested it using meta-pkgs/bulk-test-llvm.
> 
> On NetBSD 9-stable amd64, I would presume, as that is in my view the
> most important pkgsrc target?

No, I was testing on -current, since that's what I'm mostly developing
on.

> But maybe you used netbsd-current and
> that's not so different in how this will go, although the base gcc is
> older.

I've started a test on a (slower) 9.1 system.

> If it hasn't been tested on NetBSD-9/amd64 it would be good if someone
> could do that, also aarch64, and non-NetBSD.
> 
> At this point I am no longer concerned with how complicated or desktoppy
> stuff in pkgsrc works on NetBSD 8.  9 has been out for 21 months.  But
> if anybody does, they probably should test and report.
> 
> > I have not committed it yet because:
> >
> > [some breakage]
> 
> It seems like a fair bit of the breakage is fixed already, and some of
> it is in the category where we can't reasonably block updating (an
> upstream has a recent track record of not making releases that work with
> recent llvm), so the residual breakge is pretty small.

I agree with this.

> It seems good to have this in, as we're already having a bit of
> rust-llvm trouble.
> 
> On the other hand, it's only been out 6 weeks and is a .0, so we are
> hardly behind for not having it.
> 
> 
> I think the real philosophical question for these updates is whether
> it's a reasonable expectation that projects that depend on llvm (or any
> A that depends on B) is expected to be tracking B-current and ensure
> that when B has a release, then within some shortish time period, maybe
> 4 weeks, there is an A release that works with the B release.

I think that's how it works.

> Part of that can be if B is stable enough that it's almost always the
> case that a new B works fine with any actually-maintained A's most
> recent release.
> 
> My impresssion is that llvm has a good track record of not making
> breaking changes and we are dealing with a combination of unmaintained
> projects and projects that by their nature have to rely on private
> interfaces.  Is that a fair characterization?

The consumers of llvm interfaces seem to need updating for every major
llvm release.

Still, I agree with nia that I don't want to maintain multiple llvm
versions in pkgsrc, and usually such consumers are updated to match
llvm releases (though not all manage to get timely releases out the
door). I think the missing packages all have llvm 13 support in their
git heads.

I plan on committing the updates after my 9.1 build has run successfully.
 Thomas