On 29 April 2017 at 21:51, Edward Diener via Boost <boost@lists.boost.org> wrote:

What are you trying to compile/build/run ?

An application that pulls in the boost::file_system headers. I am not trying to build boost with clang. For completeness sake, I have the following PP defines: __clang__ BOOST_SP_USE_STD_ATOMIC BOOST_MSVC=1900 BOOST_HAS_MS_INT64

As explained Boost PP does not support clang-cl, which has a buggy emulation of the non-standard VC++ preprocessor.

You have expressed your point of view before and very clearly. In Boost, using:

using clang : 4.0 : some_path/clang++ : <cxxflags>-fmacro-backtrace-limit=0 <cxxflags>-Wno-invalid-token-paste <compileflags>-fmsc-version=1900 <linkflags>-fuse-ld=lld ;

I will eventually try this, thanks for it.

A change was made to Boost PP to support this by having Boost PP use a C++ standard preprocessor whenever both _MSC_VER and __clang__ was defined.

Although we can now (with the above change) build boost with clang, this also implies that we can now NOT use boost in a project on windows (i.e. with windows headers), as the C++ standard preprocessor (the one that gets used) does not play well with the Dinkumware-STL. If it is not clear what I mean, please say so.

This decision was based on the fact that VC++'s clang/c2 uses this mode and should work using the normal Boost Build clang.jam instead of clang-win.jam.

As I wrote before, the same PP errors are generated with both Clang/LLVM and Clang/C2, there is no difference in behaviour between the two. There is an additional issue that AFAICS (due to the (relatively simplistic) way things are done by the clang team) there is no way to call clang++.exe from the IDE. All compilers supplied by Clang/LLVM are just copies of the same file with different names (same hash values for all (compiler) files). A different name invokes different behaviour. msbuild calls C:\Program Files (x86)\LLVM\msbuild-bin\cl.exe (which is just another copy of the same compiler). f.e. to get the build information, one has to use different commands:

clang++ --version (linux style) clang-cl -v (windows style)

even though the only difference is the name (and therefor the command) of the files. If you (as I suspect you will) say it's a mess, I fully agree. I do think, though, that it's less usefull to be able to build boost with clang (as it also builds with VC), than it is to be able to use boost (compiled, whatever way) in a project from the IDE. boost-1.63 works (adjusted), boost-1.64 doesn't, this cannot be seen as progress IMHO. If I don't make sense or if I'm missing something, please tell me. Have a good day, degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798

On 30 April 2017 at 14:41, Peter Dimov via Boost <boost@lists.boost.org> wrote:

BOOST_MSVC=1900 looks odd; this macro should only be defined when the compiler is MSVC.

No, don't think so. Remember, both __MSC_VER and __clang__ are defined. With or without this macro, the result is the same, I tried that.

Either way, I tried

#include <boost/filesystem.hpp>

int main() { }

This works fine for me as well, I get an executable that does nothing. I also tried it (for you), even including all the headers (just to rule out some interaction) in the project concerned (many more), same result, still compiles. Optimisation at work... degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798

degski wrote:

Apologies, no, it doesn't work for me (was erronously including the 1.63 headers). What macros do you have defined? Are you compiling from the IDE?

No macros except the default (WIN32;_DEBUG;_CONSOLE;%(PreprocessorDefinitions)), yes, from the IDE. I'm not using clang 4 though, but the clang that ships with 2017.

degski wrote:

I'm also just using (a.o.) the clang that ships with 2017. I don't get it...

I checked the master branch, works. Then checked a downloaded 1_64_0, fails: 1>------ Build started: Project: testbed2017, Configuration: Debug Win32 ------ 1>testbed2017.cpp 1>In file included from testbed2017.cpp:1: 1>In file included from D:/boost_1_64_0\boost/filesystem.hpp:16: 1>In file included from D:/boost_1_64_0\boost/filesystem/path.hpp:28: 1>In file included from D:/boost_1_64_0\boost/iterator/iterator_facade.hpp:12: 1>In file included from D:/boost_1_64_0\boost/iterator/interoperable.hpp:11: 1>In file included from D:/boost_1_64_0\boost/mpl/or.hpp:43: 1>In file included from D:/boost_1_64_0\boost/mpl/aux_/include_preprocessed.hpp:37: 1>D:/boost_1_64_0\boost/mpl/aux_/preprocessed/gcc/or.hpp(63,1): error : pasting formed 'BOOST_PP_TUPLE_ELEM_O_3(', an invalid preprocessing token [-Winvalid-token-paste] 1>BOOST_MPL_AUX_NA_SPEC2( 1>^ This is exactly how clang used to fail before the changes, if I recall. I'm now checking out the boost-1.64.0 tag to see how it would fare.

On 4/30/2017 10:06 AM, Peter Dimov via Boost wrote:

...

I'm now checking out the boost-1.64.0 tag to see how it would fare.

boost-1.64.0 fails as well.

Mystery solved, the changes that fixed clang are not in 1.64.

I did not put those changes in 1.64. I did not think I had enough time between when the changes were tested on the 'develop' branch and when 1.64 was closed for all but the most serious changes. I have, as you discovered, merged those changes to master after 1.64 was out.

C:\Projects\boost-git\boost\libs\preprocessor>git log boost-1.64.0..master commit b19e4deacb7103061f9c2c9efcdd77eaa5877df0 Merge: a627594 dfc1c46 Author: Edward Diener <eldlistmailingz@tropicsoft.com> Date: Mon Apr 24 12:13:09 2017 -0400

Merge branch 'develop'

commit dfc1c46ecedef21274eb142e267e91400aa33ec8 Author: Edward Diener <eldlistmailingz@tropicsoft.com> Date: Sun Mar 26 08:51:41 2017 -0700

With _MSC_VER and __clang__ always use strict mode and variadics turned on w

commit e474eea44f00ba92310ace20add3956adb83f3de Author: Edward Diener <eldlistmailingz@tropicsoft.com> Date: Sun Mar 26 01:02:05 2017 -0700

Slight correction to particularize previous change as involving only -fno-ms

commit b03c6cd3c0f855f22f154424272ef9276ed72594 Author: Edward Diener <eldlistmailingz@tropicsoft.com> Date: Sat Mar 25 23:22:32 2017 -0700

In the configuration the combination of clang defined and gcc defined always

On 30 April 2017 at 16:15, degski <degski@gmail.com> wrote:

I'm going to do a Schwarzenegger: "I'll be back!"

I grabbed the development branch preprocessor source from github. Now it works (this limited use of boost), both with Clang/LLVM and Clang/C2. Many thanks and have a good day, degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798