[llvm-dev] A Short Policy Proposal Regarding Host Compilers

[Dean Michael Berris via llvm-dev]

On Sat, May 12, 2018 at 5:10 AM Vedant Kumar via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi,

> @Erich, thanks for putting this together :).

> On May 11, 2018, at 9:54 AM, Daniel Berlin via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> I'd be opposed to 6/5, given where it would leave us.
> It's simply hard to see a compelling reason to leave things that long.

> In particular, given this is about what it takes to produce a binary
release of clang/llvm from trunk (and not what it takes to use one), i'd
like to see some evidence/argument that using 3/1.5 would actually have a
material affect on the number of contributions, etc.
> (I have doubts it would have any affect on the abliity of new developers
to start contributing, etc).


> + 1.

> All of the clang/llvm based tools i have around (cquery, rtags, you name
it) all download and ship binary releases of clang/llvm (and FWIW, they
ship and use 1-2 year old releases).
> It's also unclear to me it makes sense to try to make sure any user can
compile the latest version - for example, researchers using it almost never
keep up with trunk, even with our current policy that supports things for
longer.  They stick with the version that existed when they started.


> So it's unclear that we are doing a thing users actually want in practice
anyway :)


> Yep, I have the same doubts. Anecdotally, I've got a few hobby projects I
haven't rebased since.. 3.4? I don't have a list on hand, but I've
definitely seen papers from groups that do the same thing.


> Finally,  given the rate of support for newer C++ standards in LLVM/GCC
seems to be accelerating and not slowing down (AFAICT), keeping a time
period this long will just put you farther and farther behind over time.


> It may be better to simply express it in terms of releases, and say "we
support the past 2/3 major gcc releases, the past 2/3 major clang releases,
and the past 2 major msvc releases"


I'm a little hesitant about this because:

- This assumes that the release cadence of these projects won't change.
Tying up the LLVM HEAD to the release rate of other projects seem dangerous.

- Using time instead seems much easier to predict and easier to plan around
(by construction I think). ;)


> I'd prefer this to imposing a fixed wait period of 3 years. We could add
a deprecation warning for compiler version X when (X+1) is released, and
switch to (X+1) when (X+2) is out. I can see this breaking down if some LTS
distro continues to ship version X, but that's in issue in the 3/1.5 scheme
as well, and we can make specific exceptions as needed.


I'm a little confused here.

I suspect the policy applies to a particular state of HEAD/trunk/master,
which means it mostly affects those who work directly on the features being
delivered in HEAD/trunk/master. For released versions, those would have
already sailed (frozen in time) and therefore we can't back-apply the
policy.

Given that, I don't see how the following won't work:

- Applying the policy to HEAD/trunk/master will/should affect the users
that *don't* track HEAD/trunk/master anyway.

- Giving a recommendation of the requirements in terms of a bootstrapping
path seems more manageable, no? i.e. if LLVM version N can build LLVM HEAD,
then if the LTS distributions can build LLVM N then they should be able to
get to LLVM HEAD.

If we're optimising for users of released versions, then there's a path for
those packaging the release(s) to use the bootstrapping approach to get to
a specific version, if the "host compiler" for their distribution can't
build the new release directly.

Now there's a real problem with the system ABI compatibility unless LLVM
decides that it will rely/require that it will only fully support working
with libc++ with the tools. With the libraries, that's a much harder
problem to solve, but I suspect the bootstrapping approach might also make
it feasible.

I understand that bootstrapping LLVM with itself introduces a lot of
potential for complexity and/or subtle bugginess along the way. But the
risk of that seems much less now, compared to tying the project's progress
to what other projects prioritise (e.g. OS distributions, other compilers,
etc.).

> I see the 3/1.5 scheme as basically a more conservative version of this,
so I'd be OK with that too.


Just to be clear, 3/1.5 works for me too. :)

Cheers

-- 
Dean