[clang][preprocessor] Testing of clang emualting the VC++ preprocessor on Windows
I have made local changes in the Boost preprocessor config.hpp on the 'develop' branch to have clang's emulation of the non-standard VC++ preprocessor act like the VC++ preprocessor as far as Boost PP is concerned. Boost PP has a large number of workarounds for VC++ without which Boost PP preprocessor code would not work when compiling using any version of VC++. I have tested the usual compilers extensively to make sure they are unaffected by these changes as well as the normal clang-linux implementation. Everything remains the same for these compilers with my changes so I am assured the changes will not affect any other compiler implementation. I was able to test both clang-3.8 and the latest build of clang, which is clang-3.9, by invoking clang-cl. My user-config.jam file for these entries looks like: using clang-win : 3.8 : SomePath/clang-cl : <compatibility>vc12 using clang-win : 3.9 : SomePath/clang-cl : <compatibility>vc14 By passing toolset=clang-win-3.8 or toolset=clang-win-3.9 I was able to successfully test these implementations against the Boost PP test code. There are quite a few failures in this clang emulation of the VC++ preprocessor when tested against the preprocessor test code. In fact testing clang emulation of VC++ preprocessor when I don't treat clang as VC++ in Boost PP, but as its normal C++ standard conforming preprocessor, still fails a few cases but far less than when clang is treated as VC++ in Boost PP. Needless to say when invoking clang-linux, which tests the normal clang implementation whether on Windows or Linux, there are no failures in the Boost PP tests. I am perfectly willing to push my changes to 'develop' for the preprocessor. The changes are essentially just in the Boost PP config.hpp file, which sets macros which control the compiler workarounds in Boost PP. As I have previously stated I am not personally willing to try to figure out or report to clang why their VC++ preprocessor emulation in Boost PP is failing, but others who are interested can do so if they wish. My personal reasons for this is that I think it is a very bad thing to attempt to replicate an already flawed C++ preprocessor in another compiler in general code. I also have spent enough time working with the VC++ preprocessor trying to find workarounds for its non-standard behavior that I do not want to do so for another preprocessor which attempts to be non-standard. I posted this to alert others to my plans to update Boost PP on 'develop' with this change, in case anybody is greatly opposed to it or wants to discuss it further. The change will not affect any other compiler but clang in VC++ preprocessor emulation mode. Unless I hear objections etc. I plan to push my update within the next day although I will wait awhile for any replies to this post.
Edward Diener wrote:
There are quite a few failures in this clang emulation of the VC++ preprocessor when tested against the preprocessor test code. In fact testing clang emulation of VC++ preprocessor when I don't treat clang as VC++ in Boost PP, but as its normal C++ standard conforming preprocessor, still fails a few cases but far less than when clang is treated as VC++ in Boost PP.
I suppose that the right thing to do here from user point of view (if that's not too much of a hassle, of course) would be to use the conforming mode for the parts that work under it, and the VC++ mode for those that work under it, and if something doesn't work with either, tough luck. :-)
On 3/30/2016 7:16 PM, Peter Dimov wrote:
Edward Diener wrote:
There are quite a few failures in this clang emulation of the VC++ preprocessor when tested against the preprocessor test code. In fact testing clang emulation of VC++ preprocessor when I don't treat clang as VC++ in Boost PP, but as its normal C++ standard conforming preprocessor, still fails a few cases but far less than when clang is treated as VC++ in Boost PP.
I suppose that the right thing to do here from user point of view (if that's not too much of a hassle, of course) would be to use the conforming mode for the parts that work under it, and the VC++ mode for those that work under it, and if something doesn't work with either, tough luck. :-)
Boost PP is not set up to switch modes. Figuring this out is not a possibility AFAICS, and it is not something I want to spend any time in doing. The problem is clearly that of clang. They have made this mess and it is not up to Boost to fix it IMO. Of course anybody else that wants to tackle this, including yourself, can do it if they like. I suggested to the clang developers, based also on some other people's comments, that it should be possible of them to setup their VC++ targeting so that the emulated VC++ preprocessor is used to expand macros when it is needed for certain header files ( Windows API, VC++ compiler distributed header files ) but that their C++ standard processor should be used otherwise. But they evidently did not want to do that. Even such a simple scheme as having a #pragma to specify one or the other preprocessor behavior they did not want to consider. Asking programmers to support another broken C++ preprocessor at this stage of C++'s development history is a travesty. And all simply because Microsoft has refused for a quarter of a century to fix their C++ preprocessor implementation, which they well know has always been non-standard.
On 31/03/2016 12:56, Edward Diener wrote:
I suggested to the clang developers, based also on some other people's comments, that it should be possible of them to setup their VC++ targeting so that the emulated VC++ preprocessor is used to expand macros when it is needed for certain header files ( Windows API, VC++ compiler distributed header files ) but that their C++ standard processor should be used otherwise. But they evidently did not want to do that. Even such a simple scheme as having a #pragma to specify one or the other preprocessor behavior they did not want to consider.
Asking programmers to support another broken C++ preprocessor at this stage of C++'s development history is a travesty. And all simply because Microsoft has refused for a quarter of a century to fix their C++ preprocessor implementation, which they well know has always been non-standard.
Presumably they both have the same motivations: trillions (or likely much higher) of lines of existing code, some unknown fraction of which might depend on the quirks of the existing behaviour. Bear in mind that one of clang's goals is not just to compile new portable programs but also existing previously-MSVC-only codebases, with minimal (or no) changes to the code. Not sure why they didn't want to have #pragma control, though, as that seems like a good compromise. Perhaps because this would require the preprocessor to track some extra metadata, since it would need to know at expansion time whether the macro was defined in a block with the pragma in effect or not -- using the pragma state at the point of expansion would be too limiting and not practically useful. This could pose some fun if non-conforming macros use conforming macros or vice versa.
On 3/30/2016 5:22 PM, Gavin Lambert wrote:
On 31/03/2016 12:56, Edward Diener wrote:
Asking programmers to support another broken C++ preprocessor at this stage of C++'s development history is a travesty. And all simply because Microsoft has refused for a quarter of a century to fix their C++ preprocessor implementation, which they well know has always been non-standard.
Yes.
Presumably they both have the same motivations: trillions (or likely much higher) of lines of existing code, some unknown fraction of which might depend on the quirks of the existing behaviour.
The current state of C++ is a many-to-many-to-many scenario: compilers x platforms x codebases x { standard } An ideal state would be many-to-one scenario: (compilers U platforms U code) x { standard } With the size of these sets growing, the latter is a scalable model; the former is not. While an ideal state may only be achievable in the limit, we should be moving in that direction--not intentionally away from it. If we do continue to move in that direction (which we must or C++ will die), the aforementioned code must break at some point. With the sets growing, the sooner it breaks the better because it just gets worse as time goes on.
Bear in mind that one of clang's goals is not just to compile new portable programs but also existing previously-MSVC-only codebases, with minimal (or no) changes to the code.
Yes, a misguided goal and deplorable mentality. Valuing popularity more highly that doing what is right results in trading future productivity for short-term expediency. This is an ethical rather than technical failure and a disservice to most of the current generation of C++ developers and all of their successors. Shame on them. Regards, Paul Mensonides
On 31/03/2016 12:56, Edward Diener wrote:
Asking programmers to support another broken C++ preprocessor at this
stage of C++'s development history is a travesty. And all simply because Microsoft has refused for a quarter of a century to fix their C++ preprocessor implementation, which they well know has always been non-standard.
Yes.
It is not accurate to blaim M$ for this. Supported (by M$) operating systems are W7SP1, W8.1 and W10 (and their server counterparts) and no others. They all come with their own compiler, and are therefore the the compilers [VS2010-VS2015] that need support (in PP or otherwise) and no more. These compilers all have C++11 support, to some extent, but progressively more of it. ...the aforementioned code must break at some point. With the sets growing,
the sooner it breaks the better because it just gets worse as time goes on.
You are perfectly correct on this one. This should apply to boost as well, and would probably make Edward's life a lot easier. Plenty of stuff concerning VC7 (*Visual C++ .NET 2002, 32-bit only*) and VC8 (*Visual C++ 2005*) in the code-base of boost (typeof/type_traits)... Valuing popularity more highly that doing what is right results in trading
future productivity for short-term expediency.
I always say, follow the money, M$ might have a hand in this. degski
On 3/31/2016 7:44 PM, degski wrote:
On 31/03/2016 12:56, Edward Diener wrote:
It is not accurate to blaim M$ for this. Supported (by M$) operating systems are W7SP1, W8.1 and W10 (and their server counterparts) and no others. They all come with their own compiler, and are therefore the the compilers [VS2010-VS2015] that need support (in PP or otherwise) and no more. These compilers all have C++11 support, to some extent, but progressively more of it.
Why do they need support? Compiler != platform. VC++ being the "de facto" compiler on the platform is a huge part of the problem. Even when they do it wrong, the others just follow along because "de facto". Perhaps clang should try to build something new rather than just wallow in the mud with the other pigs. Moreover, no C++ code should have to support any compiler whatsoever. Code should target the standard. Compilers should target the standard. Any temporary workarounds for bugs or missing features should be exactly that: temporary. -Paul
On 1 April 2016 at 06:47, Paul Mensonides <pmenso57@comcast.net> wrote: Why do they need support? Compiler != platform.
You're right, approaching it this way. vs2015 Update 2 is the only compiler that "needs" support, as it will compile code that runs on W7SP1, W8.1 and W10 (as they are the M$ supported OSes). In a world of open source and free (as in beer) compilers/OSes, this is not an issue, just upgrade to the latest and greatest. The latter, is M$'s goal, get the whole world on W10 and have forced upgrades (with a 3 month delay of execution for the enterprise edition). A lot of (in particular) companies dont' seem to like that, apparently. VC++ being the "de facto" compiler on the platform is a huge part of the
problem.
I don't really see what you intend to say here. Their platform, their compiler. Moreover, no C++ code should have to support any compiler whatsoever. Boost doesn't have to support VC++ either, correct, but it does it's best to do so. Code should target the standard. Compilers should target the standard.
Any temporary workarounds for bugs or missing features should be exactly that: temporary.
AFAIK that's what M$ is working at. Windows pre-dates Linux by over 5 years, i.e. no gcc/clang whatever. Windows predates "The Standard", you are referring to, by 13 years. The bugs and missing features ARE temporary, their time-frame differs from yours, though. M$ suffers from legacy code like any other company. Being commmercial and supporting a huge user base, I can see that they don't re-write the OS in one go, i.e. they depend on the bad choices of the past. degski
On 4/1/2016 12:25 AM, degski wrote:
On 1 April 2016 at 06:47, Paul Mensonides <pmenso57@comcast.net> wrote:
Why do they need support? Compiler != platform.
You're right, approaching it this way. vs2015 Update 2 is the only compiler that "needs" support, as it will compile code that runs on W7SP1, W8.1 and W10 (as they are the M$ supported OSes). In a world of open source and free (as in beer) compilers/OSes, this is not an issue, just upgrade to the latest and greatest.
C++ code should target the C++ Standard. Compilers should target the C++ Standard. C++ code should not have to target any compiler at all.
VC++ being the "de facto" compiler on the platform is a huge part of the
problem.
I don't really see what you intend to say here. Their platform, their compiler.
Their platform, yes, but only VC++ is their compiler. A compiler is just software running on some platform that produces executables compatible with another (possibly the same) platform. IOW, Windows is their platform, but the notion of "C++ compiler that runs on Windows or produces Windows executables" is not owned by Microsoft, nor should they be involved in it in any way (including not being "owner" of "the" C++ ABI on Windows) except maybe that of defining the executable file format (and even that is tenuous and could also be irrelevant with better QoL design in the Windows system). What all of the compilers that run on any platform (e.g. Windows: VC++, mingw, clang) should be doing is attempting to target the Standard, not copying each other's crap.
Boost doesn't have to support VC++ either, correct, but it does it's best to do so.
Unfortunately. Boost used to be a bastion of ingenuity and cutting edge practice. It is now mired in its own legacy of bending over backward (and forward) to support garbage.
Code should target the standard. Compilers should target the standard.
Any temporary workarounds for bugs or missing features should be exactly that: temporary.
AFAIK that's what M$ is working at. Windows pre-dates Linux by over 5 years, i.e. no gcc/clang whatever. Windows predates "The Standard", you are referring to, by 13 years. The bugs and missing features ARE temporary, their time-frame differs from yours, though.
Sure. What does that have to do with any other compiler? Microsoft owns Windows and owns VC++. It doesn't own clang, mingw, or any other C++ compiler that runs on Windows. Nor does it own C++. Microsoft does not get to decide what C++ is. The C++ standard committee decides that. Where VC++ is good or bad with respect to the conformance should be irrelevant to all other compilers. The standard each of them is measured against is not each other but, well, the Standard. That breeds competition rather than lock-in, and it is that competition that provides the motivation that ultimately yields improved time frames.
M$ suffers from legacy code like any other company. Being commmercial and supporting a huge user base, I can see that they don't re-write the OS in one go, i.e. they depend on the bad choices of the past.
So, "untouchable" code written in the past was compiled by a compiler in the past. Where did that compiler go? It is not like every software project depends on all of the trillions of lines of code previously written in every other project ever. -Paul
On 1 April 2016 at 23:52, Paul Mensonides <pmenso57@comcast.net> wrote: C++ code should target the C++ Standard. Compilers should target the C++
Standard. C++ code should not have to target any compiler at all.
Yes, it seems M$ agrees <https://blogs.msdn.microsoft.com/vcblog/2016/01/22/vs-2015-update-2s-stl-is-c17-so-far-feature-complete/>. It's pretty unclear what the problem is with the current state of affairs (vs2015U2), in respect of boost, old VC- and Clang-work-arounds intermingle with the new.
What all of the compilers that run on any platform (e.g. Windows: VC++, mingw, clang) should be doing is attempting to target the Standard, not copying each other's crap.
See above and work <https://blogs.msdn.microsoft.com/vcblog/2016/02/11/compiler-improvements-in-vs-2015-update-2/> is ongoing. As to MinGW, msys <https://blogs.windows.com/buildingapps/2016/03/30/run-bash-on-ubuntu-on-windows/>is history (coming soon). There's even this <https://blogs.msdn.microsoft.com/vcblog/2016/03/30/visual-c-for-linux-development/> in the making, and Clang <https://blogs.msdn.microsoft.com/vcblog/2016/03/31/clang-with-microsoft-codegen-march-2016-released/>. Don't keep going on that it's all crap.
Unfortunately. Boost used to be a bastion of ingenuity and cutting edge practice. It is now mired in its own legacy of bending over backward (and forward) to support garbage.
Exactly, (at least) part of the problem lies here (sorry to trample on peoples toes, I have great respect for all of you experts). No longer required to support garbage, see above. Microsoft does not get to decide what C++ is. The C++ standard committee
decides that.
I'm sure Herb Sutter keeps them in the loop on this one.
Where VC++ is good or bad with respect to the conformance should be irrelevant to all other compilers.
And it could be, but where's libc++ for windows, f.e.?
The standard each of them is measured against is not each other but, well, the Standard. That breeds competition rather than lock-in, and it is that competition that provides the motivation that ultimately yields improved time frames.
From the links above, the message I get is that M$ has taken op that challenge. It seems the mountain is coming to Mohammad. Give W10 and vs2015U2 a try, and be honest when giving your feedback.
So, "untouchable" code written in the past was compiled by a compiler in the past. Where did that compiler go? It is not like every software project depends on all of the trillions of lines of code previously written in every other project ever.
Exactly, why does boost need to provide for let's say 'move semantics' for compilers that date back to 2002, it's just lunacy. Just use an old version of boost with an old compiler on an old code-base and stick it all in a VM and wrap the 'crap', as you call it, in a C-api. Moreover, why would you want to incorporate move semantics in a code base, that is apparently too old and too complex to update to "The Standard" anyway. All this bending over backwards inhibits progress. degski
On 4/2/2016 2:04 AM, degski wrote:
On 1 April 2016 at 23:52, Paul Mensonides <pmenso57@comcast.net> wrote:
Don't keep going on that it's all crap.
I am not referring to VC++. I am referring to clang intentionally conforming to VC++ rather than conforming to the Standard. That decision is crap and the mentality that produced it is also crap. The same is true for any other intentional nonconformance. What it says to me is either that clang's popularity is more important to the clang project than clang doing the right thing (i.e. decisions based on benefitting clang (popularity/adoption/etc.) not on benefitting the C++ community) or that the clang project's technical decision-making is extremely shortsighted--or both.
Microsoft does not get to decide what C++ is. The C++ standard committee
decides that.
I'm sure Herb Sutter keeps them in the loop on this one.
This is about what clang is doing, not Microsoft. Microsoft has intentionally disregarded the Standard repeatedly over a long period of time. They are getting better, slowly. That's old news. Clang, however, has now made a decision to intentionally disregard the Standard as well in order to attempt conform to Microsoft's definition of C++. Microsoft lost my respect a long time ago and has yet to regain it. Clang has now lost it as well.
Where VC++ is good or bad with respect to the conformance should be irrelevant to all other compilers.
And it could be, but where's libc++ for windows, f.e.?
Indeed (w/conforming C library). But not relevant when vendors are intentionally non-conforming (e.g. clang).
The standard each of them is measured against is not each other but, well, the Standard. That breeds competition rather than lock-in, and it is that competition that provides the motivation that ultimately yields improved time frames.
From the links above, the message I get is that M$ has taken op that challenge. It seems the mountain is coming to Mohammad. Give W10 and vs2015U2 a try, and be honest when giving your feedback.
Microsoft has "taken up the challenge" more times now than I can count. I will believe it when I see it. That is not to say that VC++ isn't improving (because it is), but the pace is slow, and I have yet to see anything that leads me to believe it comes from any sense of ethics (i.e. that Microsoft's trajectory is trustworthy because the forces that drive that trajectory are ethical). WRT W8+: That is a whole other issue. Attempting to artificially turn a product into a service is not only unethical but also exploitative. It is the software equivalent of a payday loan. Microsoft is hardly alone is doing this, but W8 is where it started WRT to Windows itself. I don't care how technically good it may or may not be at that point. Regards, Paul Mensonides
On 4 Apr 2016 at 16:21, Paul Mensonides wrote:
I am not referring to VC++. I am referring to clang intentionally conforming to VC++ rather than conforming to the Standard. That decision is crap and the mentality that produced it is also crap. The same is true for any other intentional nonconformance.
Until very recently - VS2015 Update 2 - clang needed to behave like MSVC in order to grok Windows system headers. Now Windows system headers are (apparently) standards conforming, clang no longer needs to behave this way. Hence me submitting feature request https://llvm.org/bugs/show_bug.cgi?id=27169 to have winclang no longer implement a broken preprocessor except in msvc compatibility mode. (Note as of Update 2, -fms-compatibility is no longer needed to use clang with a MSVC target. An enormous improvement).
What it says to me is either that clang's popularity is more important to the clang project than clang doing the right thing (i.e. decisions based on benefitting clang (popularity/adoption/etc.) not on benefitting the C++ community) or that the clang project's technical decision-making is extremely shortsighted--or both.
I think their decision making here is far more driven by lack of resources than anything else, only a tiny - if very productive - segment of clang's dev team work on MSVC ABI support. They needed to sell to management the need for a MSVC ABI target. That means telling a very simple compelling use case story. As Microsoft have now picked up clang for Visual Studio and have finally repaired their headers, I'd call that simple story a resounding success.
This is about what clang is doing, not Microsoft. Microsoft has intentionally disregarded the Standard repeatedly over a long period of time.
The Microsoft compiler team had strong business reasons to do so. Their biggest customer is Microsoft itself, and parts of that org want a broken preprocessor and other deviations from the spec. Everyone I know in the compiler team would *just love* to conform to the standard more closely, but in the end your biggest customers drive the product.
They are getting better, slowly. That's old news. Clang, however, has now made a decision to intentionally disregard the Standard as well in order to attempt conform to Microsoft's definition of C++. Microsoft lost my respect a long time ago and has yet to regain it. Clang has now lost it as well.
Microsoft decided to resource a clang port to Visual Studio some years ago. Gaby dos Reis indeed did much of the original prototyping of clang married to C2 codegen to see if it was viable. That's now a shipping product. Microsoft are tidying and fixing up the rest of the tool ecosystem to become as standards conforming as any other ecosystem, indeed some would argue that STL has been a bit *too* standards conforming in the MSVC STL in that he has exchanged performance in a number of places for a very strict interpretation. Whatever respect you have for whom is your business, but no one can argue that very significant resources have been directed at this over many years, and it is having big effects. There is every reason to expect that the MSVC ABI target will be 98% C++ *17* standards conforming by end of 2017. Most of the missing 2% are due to legacy ABI problems e.g. the MSVC mangling system can't easily express lambda types in template args etc. That's as good as is achievable on an ABI approaching thirty years old and long preceding ISO standardisation. Microsoft are also the only vendor shipping finished editions of many of the 17 era Library Fundamentals. VS2015 ships a very high quality implementation of the Filesystem TS for example, indeed it has fewer quirks than Beman's edition in Boost. I understand that is only going to improve in the next two years as Modules, Concepts and Coroutines all land, and by 2018 it is highly likely Microsoft's C++ dev environment will meet or exceed that of any other major vendor bar none. Like you, I'll believe that when I see it, but the trends are looking excellent. Microsoft is back to being competitive in C++ after a gap of over twenty years. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 4/5/2016 3:53 AM, Niall Douglas wrote:
On 4 Apr 2016 at 16:21, Paul Mensonides wrote:
I am not referring to VC++. I am referring to clang intentionally conforming to VC++ rather than conforming to the Standard. That decision is crap and the mentality that produced it is also crap. The same is true for any other intentional nonconformance.
Until very recently - VS2015 Update 2 - clang needed to behave like MSVC in order to grok Windows system headers.
Now Windows system headers are (apparently) standards conforming, clang no longer needs to behave this way. Hence me submitting feature request https://llvm.org/bugs/show_bug.cgi?id=27169 to have winclang no longer implement a broken preprocessor except in msvc compatibility mode.
(Note as of Update 2, -fms-compatibility is no longer needed to use clang with a MSVC target. An enormous improvement).
What it says to me is either that clang's popularity is more important to the clang project than clang doing the right thing (i.e. decisions based on benefitting clang (popularity/adoption/etc.) not on benefitting the C++ community) or that the clang project's technical decision-making is extremely shortsighted--or both.
I think their decision making here is far more driven by lack of resources than anything else, only a tiny - if very productive - segment of clang's dev team work on MSVC ABI support. They needed to sell to management the need for a MSVC ABI target. That means telling a very simple compelling use case story. As Microsoft have now picked up clang for Visual Studio and have finally repaired their headers, I'd call that simple story a resounding success.
This is about what clang is doing, not Microsoft. Microsoft has intentionally disregarded the Standard repeatedly over a long period of time.
The Microsoft compiler team had strong business reasons to do so. Their biggest customer is Microsoft itself, and parts of that org want a broken preprocessor and other deviations from the spec. Everyone I know in the compiler team would *just love* to conform to the standard more closely, but in the end your biggest customers drive the product.
They are getting better, slowly. That's old news. Clang, however, has now made a decision to intentionally disregard the Standard as well in order to attempt conform to Microsoft's definition of C++. Microsoft lost my respect a long time ago and has yet to regain it. Clang has now lost it as well.
Microsoft decided to resource a clang port to Visual Studio some years ago. Gaby dos Reis indeed did much of the original prototyping of clang married to C2 codegen to see if it was viable. That's now a shipping product. Microsoft are tidying and fixing up the rest of the tool ecosystem to become as standards conforming as any other ecosystem, indeed some would argue that STL has been a bit *too* standards conforming in the MSVC STL in that he has exchanged performance in a number of places for a very strict interpretation.
Whatever respect you have for whom is your business, but no one can argue that very significant resources have been directed at this over many years, and it is having big effects. There is every reason to expect that the MSVC ABI target will be 98% C++ *17* standards conforming by end of 2017. Most of the missing 2% are due to legacy ABI problems e.g. the MSVC mangling system can't easily express lambda types in template args etc. That's as good as is achievable on an ABI approaching thirty years old and long preceding ISO standardisation.
Microsoft are also the only vendor shipping finished editions of many of the 17 era Library Fundamentals. VS2015 ships a very high quality implementation of the Filesystem TS for example, indeed it has fewer quirks than Beman's edition in Boost. I understand that is only going to improve in the next two years as Modules, Concepts and Coroutines all land, and by 2018 it is highly likely Microsoft's C++ dev environment will meet or exceed that of any other major vendor bar none.
Like you, I'll believe that when I see it, but the trends are looking excellent. Microsoft is back to being competitive in C++ after a gap of over twenty years.
And when does Microsoft actually ship a version of VC++ with a C++ standard conforming preprocessor ? Nobody is holding their breath for this just as nobody has held their breath for this over the last 25 years, during which Microsoft has repeatedly made noises that they will fix their non-standard conforming preprocessor and never have done so. All this talk of yours about how conformant to the C++ standard Microsoft is becoming means nothing unless they can fix the preprocessor. The rest of your touting of how serious Microsoft is in conforming to the C++ standard is just "show business" to me. Whatever Microsoft ships as their backend compiler, whatever noises they make about being serious about conforming as closely as possible to the C++11 or C++14 or C++17 standards, if they can't ship a C++ standards preprocessor they will never be conformant to the C++ standard.
All this talk of yours about how conformant to the C++ standard Microsoft is becoming means nothing unless they can fix the preprocessor. The rest of your touting of how serious Microsoft is in conforming to the C++ standard is just "show business" to me. Whatever Microsoft ships as their backend compiler, whatever noises they make about being serious about conforming as closely as possible to the C++11 or C++14 or C++17 standards, if they can't ship a C++ standards preprocessor they will never be conformant to the C++ standard.
It seems google is happy <https://randomascii.wordpress.com/2016/03/24/compiler-bugs-found-when-porting-chromium-to-vc-2015/>, maybe boost should tell them that you're unhappy with the preprocessor and where it's buggy? Have a good day, degski
On Tue, Apr 5, 2016 at 2:02 PM, degski <degski@gmail.com> wrote:
All this talk of yours about how conformant to the C++ standard Microsoft is becoming means nothing unless they can fix the preprocessor. The rest of your touting of how serious Microsoft is in conforming to the C++ standard is just "show business" to me. Whatever Microsoft ships as their backend compiler, whatever noises they make about being serious about conforming as closely as possible to the C++11 or C++14 or C++17 standards, if they can't ship a C++ standards preprocessor they will never be conformant to the C++ standard.
It seems google is happy <https://randomascii.wordpress.com/2016/03/24/compiler-bugs-found-when-porting-chromium-to-vc-2015/>, maybe boost should tell them that you're unhappy with the preprocessor and where it's buggy?
I don't think Google is an adequate example. From what I've seen, their coding policy is rather primitive and until recent attempts to cautiously use select C++11 features it was mostly C with classes. Boost, on the other hand, has always used C++ to its full power. No wonder that many weaker compilers choke at Boost.
Hi Andrey, I don't think Google is an adequate example. From what I've seen,
their coding policy is rather primitive and until recent attempts to cautiously use select C++11 features it was mostly C with classes. Boost, on the other hand, has always used C++ to its full power. No wonder that many weaker compilers choke at Boost.
The point I was trying to make was not whether or not google writes good code (it seems they have 50k commits a day, you seem to dismiss that readily), but rather that it apparently is possible to have a fruitfull dialog with M$ about bugs in their latest compiler, herewith suggesting that boost enter into a dialog with M$. I would think that boost carries certainly more weight than the google chrome project. On the other hand, if everybody here, as it seems to be the case, is stuck in "the glass is half empty mode" and "let's keep looking backwards", things will not progress, which I think is a shame, in the case of the (native) use of clang(-cl.exe) on windows, as it, notwithstanding the fact that they (clang) are prostituting themselves out to M$'es bad practices, produces great executables (VC doesn't stand a chance) and at the same time is very instructional and helpfull into helping people to write conformant code. Yes, I got it: "the M$-PP is shit (or crap)", now let's move forward. degski -- (\___/) (+'.'+) (")_(") This is Bunny. Copy and paste Bunny into your signature to help him gain world domination!
On Tue, Apr 5, 2016 at 4:59 PM, degski <degski@gmail.com> wrote:
Hi Andrey,
I don't think Google is an adequate example. From what I've seen, their coding policy is rather primitive and until recent attempts to cautiously use select C++11 features it was mostly C with classes. Boost, on the other hand, has always used C++ to its full power. No wonder that many weaker compilers choke at Boost.
The point I was trying to make was not whether or not google writes good code (it seems they have 50k commits a day, you seem to dismiss that readily),
The commit rate has nothing to do with code quality or C++ use. And I wasn't talking about code quality at all.
but rather that it apparently is possible to have a fruitfull dialog with M$ about bugs in their latest compiler, herewith suggesting that boost enter into a dialog with M$. I would think that boost carries certainly more weight than the google chrome project.
There is no "Boost" that could enter into dialog. The guy from Google you referenced to was paid for doing his job on reporting compiler bugs. I would guess that work took considerable amount of time, too. That is not something that could happen in a volunteer driven community. At best you could hope that particular developers interested in MSVC and Windows would be eager enough to report bugs to MS, but that is unlikely to be the case for every Boost developer. That is especially unlikely given the poor quality of MSVC over the years.
Hi Andrey, The commit rate has nothing to do with code quality or C++ use. And I
wasn't talking about code quality at all.
Surely not, but it can't be all "crap" as Paul M. likes to put it. KISS seems a good approach, if you manage the code-base Google seems to manage. C (with classes) is nothing to look down on, it just works. There is no "Boost" that could enter into dialog. The guy from Google
you referenced to was paid for doing his job on reporting compiler bugs. I would guess that work took considerable amount of time, too.
Ok, nobody "owns" the (boost) project, which highlights the weakness of the open source/volunteer approach (see posts on un-maintained projects). Couldn't the hard-core boosters form a working group and join forces? Whether this guy got/gets paid for doing so (reporting compiler bugs) is rather irrelevant, my point is that he got M$ to take on board his issues (I don't think M$ cares about whether he gets paid or not, as long it's not them doing the paying). What do YOU see as a way forward in achieving the objective of being able to use Clang/LLVM with boost on Windows? I'm not talking about compiling boost with Clang/LLVM (that's of minor importance I would say), I'm happy compiling with VC, but I would like to be able to use those VC-binaries with Clang/LLVM, i.e. the headers need to be able to deal with the platform/compiler combo. I would like to ask you to respond in terms of solutions rather than arguing points of dis-agreement. degski -- (\___/) (+'.'+) (")_(") This is Bunny. Copy and paste Bunny into your signature to help him gain world domination!
On Tue, Apr 5, 2016 at 6:01 PM, degski <degski@gmail.com> wrote:
What do YOU see as a way forward in achieving the objective of being able to use Clang/LLVM with boost on Windows? I'm not talking about compiling boost with Clang/LLVM (that's of minor importance I would say), I'm happy compiling with VC, but I would like to be able to use those VC-binaries with Clang/LLVM, i.e. the headers need to be able to deal with the platform/compiler combo.
I would like to ask you to respond in terms of solutions rather than arguing points of dis-agreement.
The answer to that has always been the same. Someone interested in clang on Windows has to get his hands dirty and make that happen. That means at least setting up regular testing and probably filing pull requests against libraries.
Hi Andrey, Someone interested in clang on Windows has to get his hands dirty and make
that happen.
Anybody interested in developping C/C++/Obj C on windows should be interested, it seems nobody is aware of Clang/LLVM on windows. That means at least setting up regular testing and probably filing pull
requests against libraries.
Is it hard to set it up? Could one (I) get help of some who are already doing this (on VC)? What about taking action on the pull requests, TypeOf seems to be stuck in 2014, is this the only one? degski -- (\___/) (+'.'+) (")_(") This is Bunny. Copy and paste Bunny into your signature to help him gain world domination!
On 2016-04-05 18:38, degski wrote:
Hi Andrey,
That means at least setting up regular testing and probably filing pull requests against libraries.
Is it hard to set it up?
I never did this myself but there is this page: http://www.boost.org/development/running_regression_tests.html
Could one (I) get help of some who are already doing this (on VC)?
I would recommend starting a new thread with an appropriate title to catch attention of the respective persons. I'm sure someone will be able to answer your questions.
What about taking action on the pull requests, TypeOf seems to be stuck in 2014, is this the only one?
I have no idea. I'm not using clang on Windows and I don't know which libraries have problems with it.
On 4/5/2016 11:38 AM, degski wrote:
Hi Andrey,
Someone interested in clang on Windows has to get his hands dirty and make
that happen.
Anybody interested in developping C/C++/Obj C on windows should be interested, it seems nobody is aware of Clang/LLVM on windows.
Clang on Windows is two different implementations. There is clang on Windows targeting mingw(-64)/gcc and there is clang on Windows targeting VC++. I have filed bugs in clang's bug tracker for clang on Windows targeting mingw(-64)/gcc but I have not had time to investigate and file bug reports for linking problems in this environment, which exist and can be seen when building some Boost non-header only libraries as well as some Boost executables for testing. I know what the basic problem is, which is that clang is not providing the same object names and visibility as gcc despite the fact that it uses the gcc linker. So linking sometimes fails. But I have not had time to track down and report specific linking problems. As far as clang on Windows targeting VC++ a major problem is clearly that clang's emulation of the VC++ preprocessor is failing. What you expect Boost to do about this I do not know, but one thing this Boost developer will not do is try to find workarounds for these failures. I did ask on the clang mailing list how I can get clang targeting VC++ to show the emulated expansion of macros that it was doing so I ( and possibly others ) could at least report to clang the exact situations where clang's emulation of the VC++ preprocessor was giving an error whereas the VC++ preprocessor was working. The reaction I got for my query was complete silence. In other words clang targeting VC++ appears to be following the VC++ path of not only producing a non-standard preprocessor but also making sure that no one can actually find out what this non-standard preprocessor is actually doing when it erroneously performs macro expansion. Therefore to me there is absolutely no point of following clang down this path no matter how popular clang's emulation of VC++ may turn out to be until the nonsense involving the preprocessor is resolved. Many Boost libraries use the Boost PP for preprocessor code so expecting these Boost libraries to work with clang targeting VC++ is a waste of time.
Andrey Semashev wrote:
At best you could hope that particular developers interested in MSVC and Windows would be eager enough to report bugs to MS, but that is unlikely to be the case for every Boost developer.
That's exactly what happened when Microsoft decided to make their compiler conform to the standard, starting with version 7.1. They gave us a direct channel to report bugs in the prerelease 7.1 compiler, which we did. We also introduced BOOST_WORKAROUND to make it easier for compiler vendors to test their new compilers on Boost without workarounds. The preprocessor quirks however are a bit different story, as fixing them will probably break an ungodly amount of code.
On 4/5/2016 12:53 AM, Niall Douglas wrote:
On 4 Apr 2016 at 16:21, Paul Mensonides wrote:
I am not referring to VC++. I am referring to clang intentionally conforming to VC++ rather than conforming to the Standard. That decision is crap and the mentality that produced it is also crap. The same is true for any other intentional nonconformance.
Until very recently - VS2015 Update 2 - clang needed to behave like MSVC in order to grok Windows system headers.
Or it needed to replace them or provide instructions for them to be fixed. Comeau C++ (EDG-based) required this back in the day. IDK about now.
Now Windows system headers are (apparently) standards conforming, clang no longer needs to behave this way. Hence me submitting feature request https://llvm.org/bugs/show_bug.cgi?id=27169 to have winclang no longer implement a broken preprocessor except in msvc compatibility mode.
(Note as of Update 2, -fms-compatibility is no longer needed to use clang with a MSVC target. An enormous improvement).
MSVC target != Windows target
I think their decision making here is far more driven by lack of resources than anything else, only a tiny - if very productive - segment of clang's dev team work on MSVC ABI support. They needed to sell to management the need for a MSVC ABI target. That means telling a very simple compelling use case story. As Microsoft have now picked up clang for Visual Studio and have finally repaired their headers, I'd call that simple story a resounding success.
The problem that I have with this is more fundamental. Microsoft should not get to unilaterally decide what C++ is on Windows--including the ABI (which by its nature can limit what parts of C++ even can be implemented). Regards, Paul Mensonides
Paul Mensonides wrote:
Microsoft should not get to unilaterally decide what C++ is on Windows--including the ABI (which by its nature can limit what parts of C++ even can be implemented).
This is not a reasonable demand. The platform ABI is traditionally defined by the platform vendor.
On 2016-04-07 23:11, Peter Dimov wrote:
Paul Mensonides wrote:
Microsoft should not get to unilaterally decide what C++ is on Windows--including the ABI (which by its nature can limit what parts of C++ even can be implemented).
This is not a reasonable demand. The platform ABI is traditionally defined by the platform vendor.
I agree that there are historical reasons for the status quo on Windows, and that MS has the upper hand in Windows evolution. But I don't think that it is unreasonable to desire some degree of unification with the rest of the world. Even Apple uses System V ABI in OS X, other proprietary UNIX also support it. I don't think this ABI is controlled by a single party. The above not only relates to ABI and C++ but also the whole Windows ecosystem. It is the most problematic plaform to develop for as it drastically differs from the POSIX world and because of that requires the largest amount of special casing.
On 4/7/2016 1:11 PM, Peter Dimov wrote:
Paul Mensonides wrote:
Microsoft should not get to unilaterally decide what C++ is on Windows--including the ABI (which by its nature can limit what parts of C++ even can be implemented).
This is not a reasonable demand. The platform ABI is traditionally defined by the platform vendor.
Platform ABI is not the same thing as C++ ABI. The platform ABI is a lower layer. Link compatibility of C++ binaries produced by different C++ implementations may require compatible (or the same) C++ ABIs, but link compatibility can break for independently built binaries for all sorts of reasons. Regards, Paul Mensonides
On 3/30/2016 5:05 PM, Edward Diener wrote:
I have made local changes in the Boost preprocessor config.hpp on the 'develop' branch to have clang's emulation of the non-standard VC++ preprocessor act like the VC++ preprocessor as far as Boost PP is concerned. Boost PP has a large number of workarounds for VC++ without which Boost PP preprocessor code would not work when compiling using any version of VC++.
I have tested the usual compilers extensively to make sure they are unaffected by these changes as well as the normal clang-linux implementation. Everything remains the same for these compilers with my changes so I am assured the changes will not affect any other compiler implementation.
I was able to test both clang-3.8 and the latest build of clang, which is clang-3.9, by invoking clang-cl. My user-config.jam file for these entries looks like:
using clang-win : 3.8 : SomePath/clang-cl : <compatibility>vc12 using clang-win : 3.9 : SomePath/clang-cl : <compatibility>vc14
By passing toolset=clang-win-3.8 or toolset=clang-win-3.9 I was able to successfully test these implementations against the Boost PP test code.
There are quite a few failures in this clang emulation of the VC++ preprocessor when tested against the preprocessor test code. In fact testing clang emulation of VC++ preprocessor when I don't treat clang as VC++ in Boost PP, but as its normal C++ standard conforming preprocessor, still fails a few cases but far less than when clang is treated as VC++ in Boost PP. Needless to say when invoking clang-linux, which tests the normal clang implementation whether on Windows or Linux, there are no failures in the Boost PP tests.
I am perfectly willing to push my changes to 'develop' for the preprocessor. The changes are essentially just in the Boost PP config.hpp file, which sets macros which control the compiler workarounds in Boost PP. As I have previously stated I am not personally willing to try to figure out or report to clang why their VC++ preprocessor emulation in Boost PP is failing, but others who are interested can do so if they wish. My personal reasons for this is that I think it is a very bad thing to attempt to replicate an already flawed C++ preprocessor in another compiler in general code. I also have spent enough time working with the VC++ preprocessor trying to find workarounds for its non-standard behavior that I do not want to do so for another preprocessor which attempts to be non-standard.
I posted this to alert others to my plans to update Boost PP on 'develop' with this change, in case anybody is greatly opposed to it or wants to discuss it further. The change will not affect any other compiler but clang in VC++ preprocessor emulation mode. Unless I hear objections etc. I plan to push my update within the next day although I will wait awhile for any replies to this post.
I pushed my update to Boost PP on 'develop' so anybody using clang targeting VC++ for Windows can try it out. It is possible that the clang emulating the non-standard VC++ preprocessor errors I see when running the preprocessor tests with clang-win toolset are few but are being propagated in many different cases. However I don't even think there is a way to see, for anybody interested, how clang is expanding macros in its VC++ emulation as opposed to normal clang-linux where macro expansion is shown when clang preprocessor erros are detected. Note on clang targeting on Windows: The LLVM 3.8 binary distribution of clang for Windows defaults to clang/clang++ targeting VC++, while all previous LLVM binary distributions of clang for Windows defaulted to clang/clang++ targeting mingw(-64)/gcc. The clang-cl executable always targets VC++ AFAIK. When you build from source using VC++ on Windows then clang/clang++ targets VC++ by default and when you build from source using mingw(-64)/gcc on Windows then clang/clang++ targets mingw(-64)/gcc by default. You can always change the targeting of clang through the use of the clang/clang++ '-target' option. It's details are poorly documented at http://clang.llvm.org/docs/CrossCompilation.html#target-triple. I chided clang developers about this incomplete documentation but without effect. I was given the targets '-target i686-pc-windows-gnu' and '-target x86_64-pc-windows-gnu' as a way of targeting mingw(-64)/gcc for 32-bit and 64-bit clang/clang++ versions respectively, both of which I have tested and do work. I believe the equivalent targets for 32-bit and 64-bit versions of clang/clang++ targeting VC++ are '-target=i686-pc-windows-msvc' and '-target=x86_64-pc-windows-msvc' respectively but I have not tried these out.
Hi, Is there a (simple) git command-line that gives me a complete "develop" boost source distribution clone, so I could give it a try? Thanks in advance, degski On 31 March 2016 at 14:28, Edward Diener <eldiener@tropicsoft.com> wrote:
On 3/30/2016 5:05 PM, Edward Diener wrote:
I have made local changes in the Boost preprocessor config.hpp on the 'develop' branch to have clang's emulation of the non-standard VC++ preprocessor act like the VC++ preprocessor as far as Boost PP is concerned. Boost PP has a large number of workarounds for VC++ without which Boost PP preprocessor code would not work when compiling using any version of VC++.
I have tested the usual compilers extensively to make sure they are unaffected by these changes as well as the normal clang-linux implementation. Everything remains the same for these compilers with my changes so I am assured the changes will not affect any other compiler implementation.
I was able to test both clang-3.8 and the latest build of clang, which is clang-3.9, by invoking clang-cl. My user-config.jam file for these entries looks like:
using clang-win : 3.8 : SomePath/clang-cl : <compatibility>vc12 using clang-win : 3.9 : SomePath/clang-cl : <compatibility>vc14
By passing toolset=clang-win-3.8 or toolset=clang-win-3.9 I was able to successfully test these implementations against the Boost PP test code.
There are quite a few failures in this clang emulation of the VC++ preprocessor when tested against the preprocessor test code. In fact testing clang emulation of VC++ preprocessor when I don't treat clang as VC++ in Boost PP, but as its normal C++ standard conforming preprocessor, still fails a few cases but far less than when clang is treated as VC++ in Boost PP. Needless to say when invoking clang-linux, which tests the normal clang implementation whether on Windows or Linux, there are no failures in the Boost PP tests.
I am perfectly willing to push my changes to 'develop' for the preprocessor. The changes are essentially just in the Boost PP config.hpp file, which sets macros which control the compiler workarounds in Boost PP. As I have previously stated I am not personally willing to try to figure out or report to clang why their VC++ preprocessor emulation in Boost PP is failing, but others who are interested can do so if they wish. My personal reasons for this is that I think it is a very bad thing to attempt to replicate an already flawed C++ preprocessor in another compiler in general code. I also have spent enough time working with the VC++ preprocessor trying to find workarounds for its non-standard behavior that I do not want to do so for another preprocessor which attempts to be non-standard.
I posted this to alert others to my plans to update Boost PP on 'develop' with this change, in case anybody is greatly opposed to it or wants to discuss it further. The change will not affect any other compiler but clang in VC++ preprocessor emulation mode. Unless I hear objections etc. I plan to push my update within the next day although I will wait awhile for any replies to this post.
I pushed my update to Boost PP on 'develop' so anybody using clang targeting VC++ for Windows can try it out. It is possible that the clang emulating the non-standard VC++ preprocessor errors I see when running the preprocessor tests with clang-win toolset are few but are being propagated in many different cases. However I don't even think there is a way to see, for anybody interested, how clang is expanding macros in its VC++ emulation as opposed to normal clang-linux where macro expansion is shown when clang preprocessor erros are detected.
Note on clang targeting on Windows:
The LLVM 3.8 binary distribution of clang for Windows defaults to clang/clang++ targeting VC++, while all previous LLVM binary distributions of clang for Windows defaulted to clang/clang++ targeting mingw(-64)/gcc.
The clang-cl executable always targets VC++ AFAIK. When you build from source using VC++ on Windows then clang/clang++ targets VC++ by default and when you build from source using mingw(-64)/gcc on Windows then clang/clang++ targets mingw(-64)/gcc by default.
You can always change the targeting of clang through the use of the clang/clang++ '-target' option. It's details are poorly documented at http://clang.llvm.org/docs/CrossCompilation.html#target-triple. I chided clang developers about this incomplete documentation but without effect.
I was given the targets '-target i686-pc-windows-gnu' and '-target x86_64-pc-windows-gnu' as a way of targeting mingw(-64)/gcc for 32-bit and 64-bit clang/clang++ versions respectively, both of which I have tested and do work. I believe the equivalent targets for 32-bit and 64-bit versions of clang/clang++ targeting VC++ are '-target=i686-pc-windows-msvc' and '-target=x86_64-pc-windows-msvc' respectively but I have not tried these out.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- (\___/) (+'.'+) (")_(") This is Bunny. Copy and paste Bunny into your signature to help him gain world domination!
On 31/03/2016 15:27, degski wrote:
Hi,
Is there a (simple) git command-line that gives me a complete "develop" boost source distribution clone, so I could give it a try?
Easiest way is to go to https://github.com/boostorg/preprocessor, and hit the "download" button ;) HTH, John.
Thanks in advance,
degski
On 31 March 2016 at 14:28, Edward Diener <eldiener@tropicsoft.com> wrote:
On 3/30/2016 5:05 PM, Edward Diener wrote:
I have made local changes in the Boost preprocessor config.hpp on the 'develop' branch to have clang's emulation of the non-standard VC++ preprocessor act like the VC++ preprocessor as far as Boost PP is concerned. Boost PP has a large number of workarounds for VC++ without which Boost PP preprocessor code would not work when compiling using any version of VC++.
I have tested the usual compilers extensively to make sure they are unaffected by these changes as well as the normal clang-linux implementation. Everything remains the same for these compilers with my changes so I am assured the changes will not affect any other compiler implementation.
I was able to test both clang-3.8 and the latest build of clang, which is clang-3.9, by invoking clang-cl. My user-config.jam file for these entries looks like:
using clang-win : 3.8 : SomePath/clang-cl : <compatibility>vc12 using clang-win : 3.9 : SomePath/clang-cl : <compatibility>vc14
By passing toolset=clang-win-3.8 or toolset=clang-win-3.9 I was able to successfully test these implementations against the Boost PP test code.
There are quite a few failures in this clang emulation of the VC++ preprocessor when tested against the preprocessor test code. In fact testing clang emulation of VC++ preprocessor when I don't treat clang as VC++ in Boost PP, but as its normal C++ standard conforming preprocessor, still fails a few cases but far less than when clang is treated as VC++ in Boost PP. Needless to say when invoking clang-linux, which tests the normal clang implementation whether on Windows or Linux, there are no failures in the Boost PP tests.
I am perfectly willing to push my changes to 'develop' for the preprocessor. The changes are essentially just in the Boost PP config.hpp file, which sets macros which control the compiler workarounds in Boost PP. As I have previously stated I am not personally willing to try to figure out or report to clang why their VC++ preprocessor emulation in Boost PP is failing, but others who are interested can do so if they wish. My personal reasons for this is that I think it is a very bad thing to attempt to replicate an already flawed C++ preprocessor in another compiler in general code. I also have spent enough time working with the VC++ preprocessor trying to find workarounds for its non-standard behavior that I do not want to do so for another preprocessor which attempts to be non-standard.
I posted this to alert others to my plans to update Boost PP on 'develop' with this change, in case anybody is greatly opposed to it or wants to discuss it further. The change will not affect any other compiler but clang in VC++ preprocessor emulation mode. Unless I hear objections etc. I plan to push my update within the next day although I will wait awhile for any replies to this post.
I pushed my update to Boost PP on 'develop' so anybody using clang targeting VC++ for Windows can try it out. It is possible that the clang emulating the non-standard VC++ preprocessor errors I see when running the preprocessor tests with clang-win toolset are few but are being propagated in many different cases. However I don't even think there is a way to see, for anybody interested, how clang is expanding macros in its VC++ emulation as opposed to normal clang-linux where macro expansion is shown when clang preprocessor erros are detected.
Note on clang targeting on Windows:
The LLVM 3.8 binary distribution of clang for Windows defaults to clang/clang++ targeting VC++, while all previous LLVM binary distributions of clang for Windows defaulted to clang/clang++ targeting mingw(-64)/gcc.
The clang-cl executable always targets VC++ AFAIK. When you build from source using VC++ on Windows then clang/clang++ targets VC++ by default and when you build from source using mingw(-64)/gcc on Windows then clang/clang++ targets mingw(-64)/gcc by default.
You can always change the targeting of clang through the use of the clang/clang++ '-target' option. It's details are poorly documented at http://clang.llvm.org/docs/CrossCompilation.html#target-triple. I chided clang developers about this incomplete documentation but without effect.
I was given the targets '-target i686-pc-windows-gnu' and '-target x86_64-pc-windows-gnu' as a way of targeting mingw(-64)/gcc for 32-bit and 64-bit clang/clang++ versions respectively, both of which I have tested and do work. I believe the equivalent targets for 32-bit and 64-bit versions of clang/clang++ targeting VC++ are '-target=i686-pc-windows-msvc' and '-target=x86_64-pc-windows-msvc' respectively but I have not tried these out.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Easiest way is to go to https://github.com/boostorg/preprocessor, and hit the "download" button ;-)
I actually did that after I posted and before you answered. I also installed VS2015 Update 2, which was released on 30.03.2016. As testing is concerned, I have the impression, that more things are broken ow than before. It would be nice, if those things that propagate get fixed (typeof/type_traits), before attempting any other changes. These problems (typeof/type_traits) appeared with Geometry, but were quite easy to work around. Yesterday I tried Spirit, which also failes too compile (as a user of it), but to me it was unfixable, no easy work around. degski
On 30 Mar 2016 at 17:05, Edward Diener wrote:
I posted this to alert others to my plans to update Boost PP on 'develop' with this change, in case anybody is greatly opposed to it or wants to discuss it further. The change will not affect any other compiler but clang in VC++ preprocessor emulation mode. Unless I hear objections etc. I plan to push my update within the next day although I will wait awhile for any replies to this post.
Interested parties may wish to subscribe to https://llvm.org/bugs/show_bug.cgi?id=27169 and gently remind clang devs of that ticket when appropriate. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
participants (8)
-
Andrey Semashev -
degski -
Edward Diener -
Gavin Lambert -
John Maddock -
Niall Douglas -
Paul Mensonides -
Peter Dimov