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

[Brooks Davis via llvm-dev]

On Sat, May 14, 2016 at 10:20:34AM +0100, David Chisnall via cfe-dev wrote:
> On 13 May 2016, at 18:44, Chris Bieneman via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> > 
> > One thing that has come to mind for me lately is that as a community we might benefit from encouraging maintainers of downstream distributions to manage their releases (at least partially) in LLVM public trees. As Fred stated at Apple we tend to fork off from trunk *way* before we ship our releases.
> 
> I think that this would require some fairly significant changes to workflow for downstream users and I don???t see it being possible for us.  In FreeBSD, we ship Clang in two ways:
> 
> 1) As the system compiler
> 2) As a third-party package
> 
> In the former case, we import all of the sources into our svn tree and integrate it with our own build system (in a horrible way).  All of the CMake-generated definitions are committed.  We then need to support this branch for a long time, so we periodically back-port fixes, though in good releases we just pull in the minor releases.
> 
> In the latter case, the source for building is already the LLVM upstream tarballs.  The ports tree has infrastructure for applying patches, so we put these in, but it doesn???t have infrastructure for fetching an arbitrary release from svn.  If LLVM moved to GitHub then this might be possible, as GitHub provides a mechanism for grabbing an arbitrary git hash as a tarball (which quite a lot of ports use).  To be honest, this isn???t much easier than maintaining a small set of patches (most of which currently are to work around the fact the clang ships with a load of C headers that conflict with definitions in FreeBSD libc).

[I'm the FreeBSD LLVM package maintainer]

I'm not really worried about patches.  Where I need them, I've got
infrastructure in place to fetch them and add them to the build system.
I tend to track minor releases and GCing patches during that process
isn't much work.  If there was a more regular stream of changes, it
would be easy enough to follow.  Mostly I apply patches when someone
actually hits a regression so people don't have to rebuild/reinstall for
patches that often don't apply to our users.  This is particularly
important to 3.8+ where shared builds have been broken for quite some
time so the full package takes up >1GB of disk space.

For llvm-devel I have a script to grab the current git checksums from
the github API.  It works well and is easy to use.  For actual releases,
I consider the tarballs to be the source of truth.

-- Brooks