Re: [1.75 release] Merging 'develop' to 'master' for Embarcadero fix

From: Edward Diener (eldiener_at_[hidden])
Date: 2020-10-28 23:30:00

On 10/28/2020 3:29 PM, Vinnie Falco via Boost wrote:
> On Wed, Oct 28, 2020 at 11:11 AM Edward Diener via Boost
> <boost_at_[hidden]> wrote:
>> A number of libraries have my PR to enable Embarcadero C++ clang-based
>> compilers for Boost in their 'develop' branch
> 
> What about new libraries, such as Boost.JSON?

I should have explained the issue with Boost and Embarcadero although I 
thought I did so in the past. Here is the issue.

The test for Borland/Codegear/Embarcadero workarounds in code should not 
solely rely on a test for the preprocessor symbol __BORLANDC__ and.or 
__CODEGEARC__. Instead the test must be done in either of two ways:

1) If config.hpp has already been include in the TU, any test for 
__BORLANDC__ should be the same test using BOOST_BORLANDC instead and 
any test for __CODEGEARC__ should be the same test using BOOST_CODEGEARC 
instead.

2) If config.hpp has not already been included in a TU, any test for 
__BORLANDC__ should be a test for !defined(__clang__) && __BORLANDC__ 
and any test for __CODEGEARC__ should be a test for !defined(__clang__) 
&& __CODEGEARC__ .

The reason for this is that the Embarcadero C++ clang-based compilers 
also define both __BORLANDC__ and __CODEGEARC__ but almost never need 
the manifold workarounds that the old bcc32 compiler, which also defines 
those preprocessor symbols, need, since the clang-based compilers are 
much more compliant to the C++ standard than the old bcc32 compiler is.

To test for the Embarcadero C++ clang-based compilers, in case a 
specific workaround is needed for those compilers you can either simply 
test for BOOST_EMBTC if config.hpp has already been included, or test 
for defined(__clang__) and __BORLANDC__ or defined(__clang__) and 
__CODEGEARC__ if config.hpp has not been included.

I can not be expected to endlessly go through a new library's code 
correcting __BORLANDC__ or __CODEGEARC__ workarounds to their correct 
equivalents, so please if you have such workarounds in your new code 
make the changes as explained above. Better yet, if you have such 
__BORLANDC__ or __CODEGEARC__ workarounds for new library code as an 
attempt to build/use your library with the old bcc32 compiler, I would 
strongly recommend to just get rid of them entirely. There is almost a 
0% chance that the bcc32 compiler can use your new library in any way.