Re: [boost] Boost and clang under Windows

Subject: Re: [boost] Boost and clang under Windows
From: Chandler Carruth (chandlerc_at_[hidden])
Date: 2013-09-29 18:15:01

On Sun, Sep 29, 2013 at 4:16 PM, Niall Douglas <s_sourceforge_at_[hidden]>wrote:

> On 29 Sep 2013 at 14:52, Beman Dawes wrote:
>
> > I don't think it occurred to them or to me during the discussions that
> > anyone would try to workaround failures before the clang folks had a
> chance
> > to introduce Microsoft compatibility fixes. I'll get back to Chandler
> with
> > a request for a public statement of their plan.
>
> I think there are multiple issues at work here, and the list is
> conflating them all as one. It might be worth disambiguating them:
>

I was going to write just such an email....

> 1. There is getting clang to compile Mingw-path Boost on Windows.
> This is fairly easy, simply configure clang to pretend to be Mingw
> and apart from some minor gotchas this works and spits out Mingw type
> PE binaries.
>

FWIW, while there are some folks in the Clang community interested in MinGW
compatibility, it has significantly fewer resources devoted to it, and
isn't my personal priority.

>
> 2. There is getting clang to compile MSVC-path Boost on Windows with
> all its quirks workarounds and special cases and code paths for
> legacy MSVCs which modern MSVCs sometimes emulate if they spot a
> legacy pattern. This is very similar to IE10 spotting IE6 patterns
> and forcing legacy behaviour to prevent legacy code breakage.
>

FWIW, we have a very strong interest in getting this to work with at least
VS2012 and VS2010. I don't think anyone is looking at compatibility on the
Clang side further back.

>
> 3. There is getting clang to compile Boost as if it were MSVC18
> (VS2013). Here the new, much less customised Dinkumware STL and much
> more conformant compiler ought to let Boost disable custom MSVC code
> paths in many cases, and adopt the GCC/clang code paths instead.
> Someone just needs to go through and try flipping code path selection
> switches to see what happens with the latest MSVC [1].
>

We also care about and will work to support VS2013 as it sees updates, but
we're still getting started here. Some things may work better with Clang,
and some things may not work at all. For example, I don't think we have any
of the Visual Studio or MSBuild integration.

> Item 2 is valuable to clang developers for debugging clang, and not
> really anyone else.

I'm hopeful that Clang's Windows support is valuable to Boost developers
and other developers using C++ on Windows.

>
> Item 3 is value adding to Boost. Item 3 is the one Boost ought to
> encourage.
>

Clang developers will also benefit from bugs here as we've yet to really
get a handle on VS2013.