...

I have been successful so far when running tests of preprocessor, mpl, type_traits, and tti with clang in Windows. I will test some more libraries but so far it looks to me that the clang developers have finally created a version under Windows which can be used to successfully test Boost libraries. This adds one more reliable testing environment under Windows. Now I can use the latest clang, various flavors of gcc under mingw, and various flavors of VC++.

Good news - and thanks for all your work on this. Paul

+1

PS How close are we to being able to use clang with the VS IDE?

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Edward Diener Sent: 14 July 2014 08:06 To: boost@lists.boost.org Subject: [boost] [clang] Using clang in Windows

Just a note to everybody about using clang in Windows. I upgraded the latest clang- linux.jam file in Boost Build on the 'develop' branch so that clang in Windows using gcc should now work for the purposes of testing Boost libraries.

If you get the latest clang and build it on Windows using CMake with any of

I'm not sure this is actually feasible? Or am I missing something big here? With today's existing technologies, you can already use GCC, clang or any other compiler with Visual Studio --- but in a rather tedious, labor-intensive and akward fashion. It is possible to create a project of type "External Makefile", manually write your own build with GNUmake or another build tool and use Visual Studio basically only for project management and editing. This is how I do cross development with microcontroller compilers such as IAR systems, GHS, GCC, etc. within the framework of VS. The big problem is getting debug information and using a debug system or emulator within the context of VS. I have not figured out how to integrate non-native compiler debugging with VS yet. Cheers Chris On Monday, July 14, 2014 7:35 PM, Paul A. Bristow wrote: the

mingw generators or Ninja, you will have a clang executable which will default to a target using gcc headers and libraries. If you add a line in user-config.jam such as:

using clang : : yourpath/clang++.exe ;

then you should be able to execute:

b2 toolset=clang

in order to run tests from withion a test directory for any Boost library using clang as your compiler. The output looks very good without any of the problems I have seen before when running clang in Windows. Just make sure you switch to the Boost Build 'develop' branch and pull the latest source.

I have been successful so far when running tests of preprocessor, mpl, type_traits, and tti with clang in Windows. I will test some more libraries but so far it looks to me that the clang developers have finally created a version under Windows which can be used to successfully test Boost libraries. This adds one more reliable testing environment under Windows. Now I can use the latest clang, various flavors of gcc under mingw, and various flavors of VC++.

Good news - and thanks for all your work on this. Paul PS How close are we to being able to use clang with the VS IDE? I've had to switch to using NetBeans to run clang and gcc under Windows but it would be less confusing to use VS. (and I've failed to get the MSVC compiler to work with NetBeans  - it did previously using VCC4N but it has stopped working for me for reasons unclear). --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 01539 561830 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

...

PS How close are we to being able to use clang with the VS IDE?

There are two problems with using clang with the VS IDE and VC++:

1) The lesser of the two problems is that we still have not worked out

way for using Boost Build with clang targeting either gcc or VC++, although we can do one or the other separately.

<snip> detailed problem description...

2) The greater of the two problems is that in order to compile with the VC++ header files clang in Windows, targeting VC++, has had to emulate a certain amount of VC++ "bugs" just to digest the header files without compile errors.

<snip> detailed problem description... May I suggest something? Sometimes an idea from an idiot such as me can provide an alternate way of thinking --- or not, or whatever. To me it seems very difficult to force clang to comprehend specialized VS headers and effectively deal with the VS preprocessor? VS is hand-crafted for the VC++ compiler and not designed to interact natively with a foreign compiler. Have you considered simply side-stepping the VS compiler for the clang compilation stage and finding the appropriate juncture point to re-connect object files with VS? This is the object file level. If the object file format can be brought into a compatible form for VS, then you do not even need to force the clang compilation stage to interoperate with the VC++ preprocessor or the VC++ headers. A big problem might be the language of the binary object files: VS = COFF / clang = ELF. If you can work around this, perhaps you can compile with clang as an external compiler and hook up to the linker and debugger after compilation at the object file level--- assuming of course that the object file binary format can somehow be made compatible with Visual Studio's COFF format. What I am saying is perhaps to simply side-step the VC++ compiler, do not use its preprocessor, and do not use its headers. Simply use clang in its entirety for compiling. You then only need to find a way to hook up to the object file binary format on the object file level. I hope I did not get something drastically wrong here, but it sounds like a problem that I dealt with previously. Cheers Chris On Monday, July 14, 2014 11:08 PM, Edward Diener wrote: On 7/14/2014 1:35 PM, Paul A. Bristow wrote:

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Edward Diener Sent: 14 July 2014 08:06 To: boost@lists.boost.org Subject: [boost] [clang] Using clang in Windows

Just a note to everybody about using clang in Windows. I upgraded the latest clang- linux.jam file in Boost Build on the 'develop' branch so that clang in Windows using gcc should now work for the purposes of testing Boost libraries.

If you get the latest clang and build it on Windows using CMake with any of the mingw generators or Ninja, you will have a clang executable which will default to a target using gcc headers and libraries. If you add a line in user-config.jam such as:

using clang : : yourpath/clang++.exe ;

then you should be able to execute:

b2 toolset=clang

in order to run tests from withion a test directory for any Boost library using clang as your compiler. The output looks very good without any of the problems I have seen before when running clang in Windows. Just make sure you switch to the Boost Build 'develop' branch and pull the latest source.

I have been successful so far when running tests of preprocessor, mpl, type_traits, and tti with clang in Windows. I will test some more libraries but so far it looks to me that the clang developers have finally created a version under Windows which can be used to successfully test Boost libraries. This adds one more reliable testing environment under Windows. Now I can use the latest clang, various flavors of gcc under mingw, and various flavors of VC++.

Good news - and thanks for all your work on this.

Paul

PS How close are we to being able to use clang with the VS IDE?

There are two problems with using clang with the VS IDE and VC++: 1) The lesser of the two problems is that we still have not worked out a way for using Boost Build with clang targeting either gcc or VC++, although we can do one or the other separately. Essentially a build of clang in Windows using gcc targets gcc by default, and a build of clang on Windows using the VS IDE targets VC++ by default. The final executables produced are essentially the same either way except for the default target. The target can also be specified via a command line -target or --target= parameter whose documentation is very poor to nonexistent, so the easiest way to use clang in Windows is to use the default target. Boost Build needs totally different .jam files depending on the clang target. For gcc as the clang target the clang-linux.jam file will now work correctly in Windows but for VC++ as the target a separate clang-win.jam is used, along with changes in clang.jam and common.jam. Vladimir Prus is aware of these issues and has mentioned that he will take a look at this when he has some time to address it. 2) The greater of the two problems is that in order to compile with the VC++ header files clang in Windows, targeting VC++, has had to emulate a certain amount of VC++ "bugs" just to digest the header files without compile errors. The most serious negative form of this emulation IMO is that clang has emulated some of the "bugs" in the very non-standard VC++ preprocessor. However the extent of the "bugs" in the VC++ preprocessor, even if the VC++ preprocessor "works" fine for the  majority of fairly simple macro processing, is large when it comes to the sort of preprocessor metaprogramming done in Boost PP and my own VMD library. These bugs all center around the fact that the VC++ preprocessor does not do macro expansion correctly, often seemingly not fully expanding macro input before the tokens are substituted in the invoking macros output. But there are a number of other things which the VC++ preprocessor gets wrong, which can only be illustrated by very complicated examples and rarely by easy cases. It is highly doubtful that clang targeting VC++ duplicates all the "bugs" and preprocessing weirdness of VC++ macro expansion, but just duplicating some of them creates another compiler with weird VC++ like problems which a library like Boost PP is asked to deal with. I know Paul Mensonides has no enthusiasm for such work and neither do I, dealing with VC++ itself has been hard enough. I made the suggestion in the clang developer's mailing list that clang targeting VC++ should act like the buggy VC++ preprocessor for macros in VC++'s header files but should be a C++ standard conforming preprocessor otherwise, possibly controlled by some pragmas, but it seems like nobody cares about this. There are just too many programmers who just want clang targeting VC++ to behave like VC++ so they can use it theirt VS IDE compiler and they don't care if doing so means that it cannot compile other C++ standard code correctly, in this particular case C++ macros. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

...

Have you considered simply side-stepping the VS compiler for the clang compilation stage and finding the appropriate juncture point to re-connect object files with VS?

I am not someone who works with clang as a clang developer, changing the clang implementation. I have just taken unto myself the task of interfacing with clang developers as a Boost library developer. The decisions about how clang itself targeting VC++ in Windows should work has been made by actual clang developers. My only interface with them, via the clang mailing list, is what can be done so that clang in Windows is able to compile/link Boost library code. They are the ones whose goal is to have clang targeting VC++ be able to use the VC++ header files and VC++ lib files to create code, whether libraries or applications.

OK, I understand.

If you want to contribute suggestions about clang you can inteface with them via the clang developers mailing list. They are not averse to hearing what an experienced Boost library developer has to say, but remember, as I have, that it is they who must do the work to make clang operational in Windows.

Yes, I might. In particular, I would like to understand how they intend to generate compatible object file binaries in COFF format.

...

This is the object file level.

If the object file format can be brought into a compatible form for VS, then you do not even need to force the clang compilation stage to interoperate with the VC++ preprocessor or the VC++ headers.

As I understand it clang does not ship with its own header/lib files whether on Windows, Linux, or the Mac. Instead it normally uses gcc's header/lib files. But in the case of Windows, aside from targeting gcc's own header/lib files it is also offering an alternative of trying to target VC++'s headers/lib files so as to be able to function as a drop-in replacement of the VC++ compiler. Also for VC++ it must be able to work with Windows SDK header/lib files.

OK, I understand. Thank you for the clarifications. Cheers Chris On Tuesday, July 15, 2014 1:20 AM, Edward Diener wrote: On 7/14/2014 6:29 PM, Christopher Kormanyos wrote:

...

...

PS How close are we to being able to use clang with the VS IDE?

...

There are two problems with using clang with the VS IDE and VC++:

...

1) The lesser of the two problems is that we still have not worked out

...

way for using Boost Build with clang targeting either gcc or VC++, although we can do one or the other separately.

<snip> detailed problem description...

...

2) The greater of the two problems is that in order to compile with the VC++ header files clang in Windows, targeting VC++, has had to emulate a certain amount of VC++ "bugs" just to digest the header files without compile errors.

<snip> detailed problem description...

May I suggest something?

Sometimes an idea from an idiot such as me can provide an alternate way of thinking --- or not, or whatever. To me it seems very difficult to force clang to comprehend specialized VS headers and effectively deal with the VS preprocessor? VS is hand-crafted for the VC++ compiler and not designed to interact natively with a foreign compiler.

Have you considered simply side-stepping the VS compiler for the clang compilation stage and finding the appropriate juncture point to re-connect object files with VS?

I am not someone who works with clang as a clang developer, changing the clang implementation. I have just taken unto myself the task of interfacing with clang developers as a Boost library developer. The decisions about how clang itself targeting VC++ in Windows should work has been made by actual clang developers. My only interface with them, via the clang mailing list, is what can be done so that clang in Windows is able to compile/link Boost library code. They are the ones whose goal is to have clang targeting VC++ be able to use the VC++ header files and VC++ lib files to create code, whether libraries or applications. If you want to contribute suggestions about clang you can inteface with them via the clang developers mailing list. They are not averse to hearing what an experienced Boost library developer has to say, but remember, as I have, that it is they who must do the work to make clang operational in Windows.

This is the object file level.

If the object file format can be brought into a compatible form for VS, then you do not even need to force the clang compilation stage to interoperate with the VC++ preprocessor or the VC++ headers.

As I understand it clang does not ship with its own header/lib files whether on Windows, Linux, or the Mac. Instead it normally uses gcc's header/lib files. But in the case of Windows, aside from targeting gcc's own header/lib files it is also offering an alternative of trying to target VC++'s headers/lib files so as to be able to function as a drop-in replacement of the VC++ compiler. Also for VC++ it must be able to work with Windows SDK header/lib files.

A big problem might be the language of the binary object files: VS = COFF / clang = ELF. If you can work around this, perhaps you can compile with clang as an external compiler and hook up to the linker and debugger after compilation at the object

file level--- assuming of course that the object file binary format can somehow be made compatible with Visual Studio's COFF format.

What I am saying is perhaps to simply side-step the VC++ compiler, do not use its preprocessor, and do not use its headers. Simply use clang in its entirety for compiling. You then only need to find a way to hook up to the object file binary format on the object file level. I hope I did not get something drastically wrong here, but it sounds like a problem that I dealt with previously.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On Tue, Jul 15, 2014 at 10:01:26AM +0100, Paul A. Bristow wrote:

Perhaps we have to wait for Microsoft to produce an (presumably) optional 'correct' pre-processor?

This wait will not be what *you* want, of course!

I thought that the problem with writing a correct preprocessor is that then they would not be able to consume their own headers and probably a lot of customer headers. That would mean restricting it to only new code against a new SDK, and you're going to have a hard time getting _that_ over the "every feature starts at -100 points" barrier. -- Lars Viklund | zao@acc.umu.se

On Tue, Jul 15, 2014 at 11:08:30AM -0400, Edward Diener wrote:

On 7/15/2014 5:46 AM, Lars Viklund wrote:

...

On Tue, Jul 15, 2014 at 10:01:26AM +0100, Paul A. Bristow wrote:

...

Perhaps we have to wait for Microsoft to produce an (presumably) optional 'correct' pre-processor?

This wait will not be what *you* want, of course!

I thought that the problem with writing a correct preprocessor is that then they would not be able to consume their own headers and probably a lot of customer headers. That would mean restricting it to only new code against a new SDK, and you're going to have a hard time getting _that_ over the "every feature starts at -100 points" barrier.

While I agree that consuming their own headers might be a problem I have my own doubts about anything but a very small percent of customer headers being affected negatively by a change to a C++ standard conforming preprocessor. Most of the strange VC++ preprocessing behavior only really shows when one is creating the sort of large scale preprocessing constructs that are found in Boost PP. I do not think many customers will do macro programming at anywhere near that level.

I'm not overly concerned about someone intentionally writing complicated preprocessing, as those kinds of people are capable of implementing their PP magic in conformant terms. I'm concerned about people that without much knowledge write ill-formed macros that the VC++ PP ends up interpreting in the way the user intends, but which a proper PP would either reject or translate differently. This is the same reason as why there's so much code out there that only builds with VC++. A lot of people throw tokens at the compiler until they stick and call it a day. It may be that most occurences of actual PP programming are not affected by the differences, but it seems that there's a _lot_ of diverging behaviour in the VC++ PP that existing macros are accidentally using.

But in either case what can be done is the creation of a set of pragmas to switch between current VC++ preprocessor and a C++ standard conforming preprocessor when it comes to macro expansion ( where essentially all the VC++ preprocessor bugs manifest themselves ). In this way one could control which macros ( VC++ header files etc. ) are subject to the current VC++ preprocessor macro expansion buggy implementation and which macros ( Boost PP et al ) are subject to a correct C++ standard preprocessor macro expansion implementation. I made this same argument on the clang developers mailing list for clang's VC++ implementation but without getting any replies. Of course if people do not understand how badly the VC++ preprocessor behaves regarding macro expansion when one does preprocessor programming beyond the simple level most people employ, then it does not matter to them how badly the VC++ preprocessor actually works because its problems do not manifest themselves in what they normally do.

A system headers, a pragma or some other way of indicating non-conformant headers would be nice. I'd attribute this to the very slim set of people that work on the clang-cl part as well, not to mention the rather fundamental dislike for clang-cl, MS and VC++ that runs throughout the cfe-dev list, at least to my impression. Just ask about 32-bit SEH some day :) -- Lars Viklund | zao@acc.umu.se

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Edward Diener Sent: 15 July 2014 15:48 To: boost@lists.boost.org Subject: Re: [boost] [clang] Using clang in Windows

On 7/15/2014 5:01 AM, Paul A. Bristow wrote:

...

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Edward Diener Sent: 14 July 2014 22:08 To: boost@lists.boost.org Subject: Re: [boost] [clang] Using clang in Windows

On 7/14/2014 1:35 PM, Paul A. Bristow wrote:

...

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Edward Diener Sent: 14 July 2014 08:06 To: boost@lists.boost.org Subject: [boost] [clang] Using clang in Windows

Just a note to everybody about using clang in Windows

...

Perhaps we have to wait for Microsoft to produce an (presumably) optional 'correct' pre-processor?

I recall some post about this related to one of the Boost developers talking to Herb Sutter about the non-standard VC++ preprocessor and getting a verbal promise

Microsoft would finally produce a standard conforming C++ preprocessor for VC++. But I believe that Microsoft has made similar "noises" in that direction over

<snip> that the years

and nothing has ever happened so I am not sanguine about it happening anytime soon.

...

This wait will not be what *you* want, of course!

What I do not want is to have to try to hack Boost PP in order to make clang targeting VC++ work. To clang's credit when I ran the Boost PP tests, which I have largely expanded, in the 'develop' branch against the clang VC++ implementation, only a single test failed due to clang emulating VC++ preprocessor bugs.

I have argued vehemently in the clang developer mailing list that, although I do now understand that clang targeting VC++ has to emulate some of VC++'s

bugs in order to compile the VC++ header files, clang targeting VC++ should otherwise be a C++ standard conforming preprocessor for all other code. This could be done pretty nicely via a pragma. But it does not seem to have made much of an impression on others there. Many clang developers/users are so happy that they can use clang in place of VC++ in the VS IDE that they cannot understand what a

Can we produce any collective Boost wish to help this to happen? preprocessor poor

C++ preprocessor VC++ is when one goes beyond fairly simple macro expansion techniques, as of course Boost PP does.

I think you may appear to the Clangers to be a 'lone' (perhaps loony? ;-) PP enthusiast. Can we produce any collective Boost wish to help this to happen? Although it is a can of worms, there must be some way to meet peoples needs, as you explain above. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 01539 561830

On 7/15/2014 11:16 AM, Paul A. Bristow wrote:

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Edward Diener Sent: 15 July 2014 15:48 To: boost@lists.boost.org Subject: Re: [boost] [clang] Using clang in Windows

On 7/15/2014 5:01 AM, Paul A. Bristow wrote:

...

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Edward Diener Sent: 14 July 2014 22:08 To: boost@lists.boost.org Subject: Re: [boost] [clang] Using clang in Windows

On 7/14/2014 1:35 PM, Paul A. Bristow wrote:

...

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Edward Diener Sent: 14 July 2014 08:06 To: boost@lists.boost.org Subject: [boost] [clang] Using clang in Windows

Just a note to everybody about using clang in Windows

<snip>

...

...

Perhaps we have to wait for Microsoft to produce an (presumably) optional 'correct' pre-processor?

I recall some post about this related to one of the Boost developers talking to Herb Sutter about the non-standard VC++ preprocessor and getting a verbal promise that Microsoft would finally produce a standard conforming C++ preprocessor for VC++. But I believe that Microsoft has made similar "noises" in that direction over the years and nothing has ever happened so I am not sanguine about it happening anytime soon.

Can we produce any collective Boost wish to help this to happen?

Abracadabra <g> ! or "When you wish upon a star it makes no difference who you are, your dreams come true." <g><g> ! My sense of humor comes out when I think that the technical know-how of even very good programmers is going to change the motivation of the richest software company in the world to do anything technically that does not increase its profits in the long run. This is not a knock on Microsoft per se but just an acknowledgment of the reality of capitalism in the world I live in. You have to prove to them that by not doing something correctly which they have done in their own way which apparently "works" for them that they will lose customers ( developers in this case ). Considering that Visual Studio is almost certainly the most popular development environment for Windows programming and that there is probably less competition in that area than there has ever been, I have a hard time seeing this happening. Of course if a C++ guru like Herb Sutter makes this happen, all the better, but haven't we all heard this sort of thing before ?

...

...

This wait will not be what *you* want, of course!

What I do not want is to have to try to hack Boost PP in order to make clang targeting VC++ work. To clang's credit when I ran the Boost PP tests, which I have largely expanded, in the 'develop' branch against the clang VC++ implementation, only a single test failed due to clang emulating VC++ preprocessor bugs.

I have argued vehemently in the clang developer mailing list that, although I do now understand that clang targeting VC++ has to emulate some of VC++'s preprocessor bugs in order to compile the VC++ header files, clang targeting VC++ should otherwise be a C++ standard conforming preprocessor for all other code. This could be done pretty nicely via a pragma. But it does not seem to have made much of an impression on others there. Many clang developers/users are so happy that they can use clang in place of VC++ in the VS IDE that they cannot understand what a poor C++ preprocessor VC++ is when one goes beyond fairly simple macro expansion techniques, as of course Boost PP does.

I think you may appear to the Clangers to be a 'lone' (perhaps loony? ;-) PP enthusiast.

Most probably. But on a practical basis many Boost libraries use Boost PP so if there are problems in Boost PP for a particular compiler it could easily affect an end-user's ability to use a Boost library. That was my larger concern with arguing about clang for VC++'s unfortunate consequence of emulating VC++ preprocessor bugs.

Can we produce any collective Boost wish to help this to happen?

Although it is a can of worms, there must be some way to meet peoples needs, as you explain above.

I made my pitch on the clang developers mailing list for a pragma to control either correct or VC++-like macro expansion. I also said for myself, in no uncertain terms, that I am not willing to hack Boost PP further for a compiler which emulates some subset of VC++ preprocessor bugs. I highly doubt if Paul Mensonides will either. Even if VC++ were to announce that starting this minute their latest VC++ implementation has a completely C++ standard-conforming preprocessor, I am sure clang using VC++ would still support the emulation bugs they have incorporated in it in order to support already existing versions of VC++. My own point of view regarding clang in Windows is that their use of gcc/mingw works fine and I have little practical use for substituting clang in place of VC++ in the Visual Studio IDE.

On 7/15/2014 1:44 PM, loic.actarus.joly@numericable.fr wrote:

...

Most probably. But on a practical basis many Boost libraries use Boost PP so if there are problems in Boost PP for a particular compiler it could easily affect an end-user's ability to use a Boost library. That was my larger concern with arguing about clang for VC++'s unfortunate consequence of emulating VC++ preprocessor bugs.

Should they still do? Are there still so many uses for Boost PP ow that most compilers understand variadic templates?

There are approximately 45 Boost libraries out of a total of about 125 libraries that use Boost PP in some form. It is up to the individual library developer whether variadic templates will work instead of using Boost PP. In my own tti library I see no way of passing the name of the element being introspected except through a macro, much less the template parameter list when attempting to introspect a nested class template. There are still things for which a macro library like Boost PP are very useful.

On 07/18/2014 03:58 AM, Richard wrote:

"Paul A. Bristow" spake the secret code

...

From: Edward Diener Sent: 15 July 2014 15:48

...

On 7/15/2014 5:01 AM, Paul A. Bristow wrote:

...

...

...

Perhaps we have to wait for Microsoft to produce an (presumably) optional 'correct' pre-processor?

I recall some post about this related to one of the Boost developers talking to Herb Sutter about the non-standard VC++ preprocessor and getting a verbal promise that Microsoft would finally produce a standard conforming C++ preprocessor for VC++. But I believe that Microsoft has made similar "noises" in that direction over the years and nothing has ever happened so I am not sanguine about it happening anytime soon.

Can we produce any collective Boost wish to help this to happen?

My suggestion has been to identify (or create) the issues on connect that call out the non-conformant behavior and have the entire community vote them up and comment on them. Most open issues against the compiler or the IDE have one or two votes. It's easy to disregard these as having minimal impact on the user base. Even if it was only *library authors* that upvoted these issues on connect, they would stand out significantly. If lots of boost/C++ users upvoted them, then it would stand out in a huge way.

Not a bad idea, but how do you engage boost users in this if boost libraries and clang features are so nice about hiding it for them. I am thinking it may be time to be less gentle on new none compliant compiler versions. Why don't Boost attempt to remind Boost users and their compiler vendors that there are underlying non compliant compiler and standard library issues, in this case with the MS header files and preprocessor, that is complicating the availability, maintenance and improvement of the Boost libraries. One slightly radical but perhaps effective method would be to provide custom diagnostics, e.g. compiler warning and errors as appropriate. triggered by work around macros in Boost. The diagnostics should have a direct link to a page on Boost Wiki (or similar) that states the purpose of the diagnostics. Then state the status related to the goals of the Wiki page and suggested actions to take by users to help. The Wiki page should state how it is possible to silence the compiler warnings, but encourage users to take suggested actions before silencing the diagnostics. For Clang on Windows using MS headers this could be done. I am also thinking it should be done for new MS compilers. The alternative to be less gentle now about these issues is to accept that MS and others may continue having compliance issues that Boost have to work around. So when using MSVC 2025 compiler or libraries, Boost will still need to maintain and create new tweaks for this sort of issues. It would be bad if their C++11, and C++14 "feature complete" compilers does not have this fixed. It would be scary if users of their C++17 compilers still suffer. -- Bjørn

On Fri, 18 Jul 2014 06:47:55 -0700, Edward Diener wrote:

On 7/18/2014 7:50 AM, Bjørn Roald wrote: [snip]

...

I am thinking it may be time to be less gentle on new none compliant compiler versions. Why don't Boost attempt to remind Boost users and their compiler vendors that there are underlying non compliant compiler and standard library issues, in this case with the MS header files and preprocessor, that is complicating the availability, maintenance and improvement of the Boost libraries. One slightly radical but perhaps effective method would be to provide custom diagnostics, e.g. compiler warning and errors as appropriate. triggered by work around macros in Boost. The diagnostics should have a direct link to a page on Boost Wiki (or similar) that states the purpose of the diagnostics. Then state the status related to the goals of the Wiki page and suggested actions to take by users to help. The Wiki page should state how it is possible to silence the compiler warnings, but encourage users to take suggested actions before silencing the diagnostics.

[snip]

A separate diagnostic library based on macros could work to do this. But we should of course allow the end-user to turn on or off such compiler diagnostics messages.

Should it? I thought the whole point is to sufficiently bug users so that they put enough pressure on their compiler vendors to become standards conformant.

On 07/15/2014 09:51 AM, Edward Diener wrote:

On 7/15/2014 10:53 AM, Eric Niebler wrote:

...

On 7/14/2014 12:06 AM, Edward Diener wrote:

...

Just a note to everybody about using clang in Windows. I upgraded the latest clang-linux.jam file in Boost Build on the 'develop' branch so that clang in Windows using gcc should now work for the purposes of testing Boost libraries.

<snip>

How is this better than building clang with gcc under cygwin or mingw on Windows?

That is what I was describing ! Evidently I was not clear enough. The change to clang-linux.jam in the Boost Build develop branch sets the threading model for clang with gcc on Windows to -pthread rather than the previous -mthreads, which was causing problems. Its a small change but then again I will never claim credit for being a bjam programmer <g>. Testing this build of clang on Windows targeting mingw/gcc with various Boost libraries seems to work very well for me. If all this is already known I apologize for the redundancy but I am very happy about having another excellent compiler under Windows with which I can test.

Certainly! I've been using clang on Windows this way for a very long time. I do remember hitting the -mthreads problem at one point (and complaining about it on the Boost.Build mailing list to no avail). I don't remember how I worked around the problem. :P Kind of sad that we have a build system that few people understand, and whose bits are rotting. Thanks for patching it up! Eric