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

[David Chisnall via llvm-dev]

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).

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/20160514/1a3f81ad/attachment.bin>