Re: Embarcadero C++ and Boost libraries

From: Edward Diener (eldiener_at_[hidden])
Date: 2020-05-01 22:58:58

On 5/1/2020 11:59 AM, Andrey Semashev via Boost wrote:
> On 2020-05-01 18:50, Edward Diener via Boost wrote:
>> On 5/1/2020 10:37 AM, Andrey Semashev via Boost wrote:
>>> On 2020-03-30 19:45, Edward Diener via Boost wrote:
>>>>
>>>> 2) Updating Boost Config to support the clang-based compilers. I 
>>>> have done this and the PR has been merged to 'develop' on Boost Config.
>>>>
>>>> 3) In the update to Boost Config, I have created these macros:
>>>>
>>>> a) BOOST_BORLANDC = __BORLANDC__ with __clang__ not defined
>>>> b) BOOST_CODEGEARC = __CODEGEARC__ with __clang__ not defined
>>>> c) BOOST_EMBTC = Embarcadero C++ compilers with __clang__ defined
>>>
>>> Are these macros not documented in Boost.Config?
>>
>> They are not documented in the Boost.Config documentation. But neither 
>> are any other BOOST_ compiler specific macros.
> 
> They are documented here:
> 
> https://github.com/boostorg/config/blob/205b5451822f8e0ad24d62a0c47575178dce20c8/doc/macro_reference.qbk#L1349 
> 
> 
> See BOOST_MSVC, BOOST_GCC, BOOST_CLANG, etc.
> 
>> BOOST_BORLANDC = __BORLANDC__ && !__clang__
>> BOOST_CODEGEARC = __CODEGARC__ && !__clang__
>> BOOST_EMBTC = __CODEGEARC__ && __clang__
>>
>> I did not want to have to type the equivalent of the long form 
>> whenever Boost config.hpp was included in some library's code, so I 
>> created the macros in borland.hpp and embarcadero.hpp in Boost.Config. 
>> In cases in a library's code where Boost config.hpp is not being 
>> included in some TU (rare) I create the equivalent of the long form as 
>> my fix.
>>
>> The idea of my PRs to incorporate Embracadero's clang-based compilers 
>> into Boost was to change all the old references to __BORLANDC__ and 
>> __CODEGEARC__ to BOOST_BORLANDC and BOOST_CODEGEARC respectively so 
>> that the Embarcadero clang based compilers are not affected by them. 
>> There are still bugs in the Embarcadero clang based compilers, but 
>> much, much less than in the old bcc32.
> 
> Having the dedicated macros to detect particular compilers is fine. But 
> we need to document what those macros mean (i.e. which compilers they 
> represent).

I have PR ed a fix to document the macros in Boost.Config.