Re: [boost] Boost and clang under Windows

Subject: Re: [boost] Boost and clang under Windows
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2013-09-29 17:16:21

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:

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.

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.

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

Item 1 is an easy add to Boost Build, though I struggle to see the 
value add for Boost apart from clang AST parsing on Windows.

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

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

Note that Item 2 and Item 3 are not mutually incompatible. Item 3 can 
be implemented with no damage done to Item 2 with the right design. 
If clang's developers want Item 2, they can supply the appropriate 
preprocessor macros to have Boost output the quirkest, most 
MSVC-specific possible code. Meanwhile, Boost can move ahead by 
removing MSVC quirk code paths for newer MSVCs, something I think 
everyone will agree would be a huge win in maintenance and bugs.

[1]: It took a bit of creativity and effort, but I now have a single 
C++ path for VS2013 and GCC and clang in Boost.AFIO. Exact same C++ 
for all three compilers. I'm very pleased with VS2013, it's a huge 
improvement.

Niall

-- 
Currently unemployed and looking for work.
Work Portfolio: http://careers.stackoverflow.com/nialldouglas/