Boost logo

Boost :

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/



Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk