Re: [boost] [preprocessor] PR decision for Intel C++ 17 on up on Windows

Subject: Re: [boost] [preprocessor] PR decision for Intel C++ 17 on up on Windows
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-10-27 16:54:28

On 10/27/2016 4:35 PM, Andrey Semashev wrote:
> On Thu, Oct 27, 2016 at 11:11 PM, Edward Diener <eldiener_at_[hidden]> wrote:
>> I need some guidance from Boost developers in general.
>>
>> A PR has been issued for Boost PP which only affects Intel C++ 17 on up in
>> Windows. I can ascertain that only this compiler in Windows is affectd by
>> the PR. Needless to say I do not test this personally because it costs a
>> decent amount of money to buy a license. Intel does graciously offer free
>> licenses for Intel C++ on Linux for Boost developers and I have used it to
>> test the compiler under Linux. Also there are no regression tests for Intel
>> C++ on Windows in the 'develop' or 'master' regression test matrices.
>>
>> While the person who issued the PR ascertains that it fixes problems for
>> Boost libraries he uses with Intel C++ 17 on Windows the nature of the PR is
>> drastic enough that it could easily break other libraries if the changes in
>> the PR does not correspond to Intel C++ preprocessing in all cases. So my
>> quandary is what to do about the PR.
>>
>> The PR is at
>> https://github.com/boostorg/preprocessor/pull/9#issuecomment-256741882. It
>> is another one of these cases, like clang targeting VC++, where a compiler
>> implementation on Windows wants to emulate the non-standard VC++
>> preprocessor but can't quite get it right ( as if emulating a broken
>> preprocessor should ever be right ).
>>
>> Thoughts ? Ideas ? Suggestions ?
>
> Assuming you don't mind adding more workarounds to the library and
> thus complicating it, and you understand what the PR does, I think
> it's pretty safe to trust the submitter and merge it. You will see if
> it affects other compilers (the ones in the test matrix and listed as
> the officially supported), and hopefully this will also fix the
> compiler we don't test.

I know it won't affect other compilers as I can easily tell that from 
the PR. I am just worried it will break for users of Intel C++ 17 on 
Windows using other Boost libraries. Furthermore if it does break 
anything else in that environment I am not going to spend any time 
trying to figure out what to do other than to back out the fix. I have 
already said that there is no way I will personally play around with a 
compiler trying to emulate the broken VC++ preprocessor, even if I did 
have access to it, which I do not.

> If it doesn't (or if it breaks something on
> the unsupported compiler), that's not such a big deal. You will likely
> hear about it anyway.

That's fine and my reaction will be to back out the PR unless someone 
else wants to submit another one to "fix" the problem.