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

[Dean Michael Berris via llvm-dev]

On Sat, 12 May 2018 at 11:26 am, Bruce Hoult <bruce at hoult.org> wrote:

> On Sat, May 12, 2018 at 12:56 PM, Dean Michael Berris via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> - 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.
>>
>
> ​I agree with this, except that the intermediate​ compiler could be llvm
> or gcc (or another).
>

Why not just say that LLVM is required as the intermediate compiler, when
bootstrapping? I can see this being an issue with targets/platforms where
the required intermediate compiler might not support that backend yet, but
they’d have the same problem if the host compiler can’t get to LLVM HEAD
yet anyway. That makes me think that to solve that problem, developers
interested in making LLVM work for that platform will have to do something
like cross-compiling while working to get it working upstream anyway — and
then the host compiler requirements will apply to them.

In fact I *think* this is how we’d gotten the Windows port of clang working
with MSVC as the host compiler. I could be wrong, in which case I’d be
happy to be corrected.

The question becomes whether we’d need to impose that on all other
developers/users tracking HEAD (i.e. hold them back because some users
might need a special set-up).


> I think building *one* intermediate compiler is not too onerous.
>
> clang 3.4 is probably a good choice if you only want to use C++14
> features, not C++17. It demands only C++98 from the system compiler, but
> supports C++11 and C++14.
>
> If you want to use C++17 features then you need a Clang that itself needs
> the system compiler to support C++11 compiler to build it. Maybe we're
> there already.
>

This is my same thinking. We can already find a way to get LLVM to build
first then build different versions progressively to get the to language
standard we’d like to use. This seems the most forward compatible approach
compared to the alternative (status quo).
-- 
Dean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180513/b52faed6/attachment.html>