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.