Support for Embarcadero clang-based C++ compilers #327
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -19,7 +19,7 @@ | |
| # include BOOST_ABI_PREFIX | ||
| #endif | ||
|
|
||
| #if defined( BOOST_BORLANDC ) | ||
| #pragma nopushoptwarn | ||
| #endif | ||
|
|
||
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -20,8 +20,6 @@ | |
| # include BOOST_ABI_SUFFIX | ||
| #endif | ||
|
|
||
| #if defined( BOOST_BORLANDC ) | ||
| #pragma nopushoptwarn | ||
| #endif | ||
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -9,6 +9,139 @@ | |
|
|
||
| // CodeGear C++ compiler setup: | ||
|
|
||
| #ifdef __clang__ // Clang enhanced Windows compiler | ||
|
|
||
| # include "clang.hpp" | ||
| # define BOOST_NO_CXX11_THREAD_LOCAL | ||
| # define BOOST_NO_CXX11_ATOMIC_SMART_PTR | ||
|
|
||
| # ifndef __MT__ /* If compiling in single-threaded mode, assume there is no CXX11_HDR_ATOMIC */ | ||
| # define BOOST_NO_CXX11_HDR_ATOMIC | ||
| # endif | ||
|
|
||
| #define BOOST_NO_FENV_H /* temporarily disable this until we can link against fegetround fesetround feholdexcept */ | ||
| #define BOOST_NO_CXX11_HDR_EXCEPTION /* Reported this bug to Embarcadero with the latest C++ Builder Rio release */ | ||
|
|
||
| // | ||
| // check for exception handling support: | ||
| // | ||
| #if !defined(_CPPUNWIND) && !defined(__EXCEPTIONS) && !defined(BOOST_NO_EXCEPTIONS) | ||
| # define BOOST_NO_EXCEPTIONS | ||
| #endif | ||
|
|
||
| /* | ||
|
|
||
| // On non-Win32 platforms let the platform config figure this out: | ||
| #ifdef _WIN32 | ||
| # define BOOST_HAS_STDINT_H | ||
| #endif | ||
|
|
||
| // | ||
| // __int64: | ||
| // | ||
| #if !defined(__STRICT_ANSI__) | ||
| # define BOOST_HAS_MS_INT64 | ||
| #endif | ||
| // | ||
| // all versions have a <dirent.h>: | ||
| // | ||
| #if !defined(__STRICT_ANSI__) | ||
| # define BOOST_HAS_DIRENT_H | ||
| #endif | ||
| // | ||
| // Disable Win32 support in ANSI mode: | ||
| // | ||
| # pragma defineonoption BOOST_DISABLE_WIN32 -A | ||
| // | ||
| // MSVC compatibility mode does some nasty things: | ||
| // TODO: look up if this doesn't apply to the whole 12xx range | ||
| // | ||
| #if defined(_MSC_VER) && (_MSC_VER <= 1200) | ||
| # define BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP | ||
| # define BOOST_NO_VOID_RETURNS | ||
| #endif | ||
| // | ||
|
|
||
| */ | ||
|
|
||
| // Specific settings for Embarcadero drivers | ||
| # define BOOST_EMBTC __CODEGEARC__ | ||
| # define BOOST_EMBTC_FULL_VER ((__clang_major__ << 16) | \ | ||
| (__clang_minor__ << 8) | \ | ||
| __clang_patchlevel__ ) | ||
|
|
||
| // Detecting which Embarcadero driver is being used | ||
| #if defined(BOOST_EMBTC) | ||
| # if defined(_WIN64) | ||
| # define BOOST_EMBTC_WIN64 | ||
| # define BOOST_EMBTC_WINDOWS | ||
| # ifndef BOOST_USE_WINDOWS_H | ||
| # define BOOST_USE_WINDOWS_H | ||
| # endif | ||
| # elif defined(_WIN32) | ||
| # define BOOST_EMBTC_WIN32C | ||
| # define BOOST_EMBTC_WINDOWS | ||
| # ifndef BOOST_USE_WINDOWS_H | ||
| # define BOOST_USE_WINDOWS_H | ||
| # endif | ||
| # elif defined(__APPLE__) && defined(__arm__) | ||
| # define BOOST_EMBTC_IOSARM | ||
| # define BOOST_EMBTC_IOS | ||
| # elif defined(__APPLE__) && defined(__aarch64__) | ||
| # define BOOST_EMBTC_IOSARM64 | ||
| # define BOOST_EMBTC_IOS | ||
| # elif defined(__ANDROID__) && defined(__arm__) | ||
| # define BOOST_EMBTC_AARM | ||
| # define BOOST_EMBTC_ANDROID | ||
| # elif | ||
| # if defined(BOOST_ASSERT_CONFIG) | ||
| # error "Unknown Embarcadero driver" | ||
| # else | ||
| # warning "Unknown Embarcadero driver" | ||
| # endif /* defined(BOOST_ASSERT_CONFIG) */ | ||
| # endif | ||
| #endif /* defined(BOOST_EMBTC) */ | ||
|
|
||
| #if defined(BOOST_EMBTC_WINDOWS) | ||
| // About TR1 headers and features: | ||
| // BOOST_HAS_TR1_*-style definitions are placed in "boost\tr1\detail\config.hpp", | ||
| // because there, they will always be found, but here, they may be not check. | ||
|
|
||
| // // This is needed to allow 64-bit integers in cstdint.hpp | ||
| //# define BOOST_HAS_MS_INT64 | ||
|
|
||
| //# define BOOST_HAS_RVALUE_REFS | ||
|
|
||
| // // Boost.Fusion should not use its preprocessed templates, | ||
| // // due to we can use its variadic cpp11 templates. If that | ||
| // // macro is not defined it tries to use both at the same time | ||
| // // giving a redefinition error. | ||
| //# define BOOST_FUSION_DONT_USE_PREPROCESSED_FILES | ||
|
|
||
| // // Bcc64 don't have this <fenv.h> header | ||
| //# define BOOST_NO_FENV_H | ||
|
|
||
| // // This is not necessary with the last versions of bcc64 | ||
| //# if !defined(__FUNC__) | ||
| //# define __FUNC__ __func__ | ||
| //# endif | ||
|
|
||
| // FVTODO: This was uncommended with 1_55 - prolly worth testing this by uncommenting it. | ||
| // Dinkumware on Win32 and Win64 platforms has <cstdint> | ||
| // # define BOOST_HAS_STDINT_H | ||
| #endif /* BOOST_EMBTC_WINDOWS */ | ||
|
|
||
| # undef BOOST_COMPILER | ||
| # define BOOST_COMPILER "Embarcadero-Clang C++ version " BOOST_STRINGIZE(__CODEGEARC__) " clang: " __clang_version__ | ||
| // # define __CODEGEARC_CLANG__ __CODEGEARC__ | ||
| // # define __EMBARCADERO_CLANG__ __CODEGEARC__ | ||
| // # define __BORLANDC_CLANG__ __BORLANDC__ | ||
|
|
||
| #else // #if !defined(__clang__) | ||
|
|
||
| # define BOOST_CODEGEARC __CODEGEARC__ | ||
| # define BOOST_BORLANDC __BORLANDC__ | ||
|
Comment on lines
+142
to
+143
There was a problem hiding this comment. This breaks the whole point of There was a problem hiding this comment. It does not. The definition is only made when CODEGEARC is originally defined, meaning the Borland/Codegear/Embarcadero C++ compilers, and when clang is not defined, meaning that it is not the Embarcadero C++ clang-based compiler(s). There is no other compiler that defines BORLANDC and CODEGEARC anywhere. There was a problem hiding this comment. It does, you are defining both simultaneously. There was a problem hiding this comment. What is the difference. Both __BORLANDC__ and __CODEGEARC__ are always defined to the same value whenever __CODEGEARC__ is defined. I want both BOOST_BORLANDC and BOOST_CODEGEARC defined whenever the non-clang-based compilers are detected. There was a problem hiding this comment. There is no point in having both when they mean the same thing, it only produces a confusion There was a problem hiding this comment. Both are needed because there is code in other libraries referrring to the old bcc32 compiler using both __BORLANDC__ and __CODEGEARC__. There was a problem hiding this comment. @jzmaddock is the intention that there should only ever be one BOOST_COMPILER macro defined? There was a problem hiding this comment.
Yes but that's not really the mistake here: Borland and Codegear are the same compiler give or take a few updates, we should probably have kept the same header and name. Personally I think it's fine to define both under these circumstances. Note that with the Sun->Oracle name change we've basically just ignored the issue and continued calling it "sunpro" and no one seems to have complained (yet). |
||
|
|
||
| #if !defined( BOOST_WITH_CODEGEAR_WARNINGS ) | ||
| // these warnings occur frequently in optimized template code | ||
| # pragma warn -8004 // var assigned value, but never used | ||
|
|
@@ -20,7 +153,7 @@ | |
| // | ||
| // versions check: | ||
| // last known and checked version is 0x621 | ||
| #if (__CODEGEARC__ > 0x740) | ||
| # if defined(BOOST_ASSERT_CONFIG) | ||
| # error "boost: Unknown compiler version - please run the configure tests and report the results" | ||
| # else | ||
|
|
@@ -78,6 +211,8 @@ | |
| # define BOOST_HAS_PRAGMA_ONCE | ||
| #endif | ||
|
|
||
| #define BOOST_NO_FENV_H | ||
|
|
||
| // | ||
| // C++0x macros: | ||
| // | ||
|
|
@@ -124,6 +259,7 @@ | |
| #define BOOST_NO_CXX11_REF_QUALIFIERS | ||
| #define BOOST_NO_CXX11_FINAL | ||
| #define BOOST_NO_CXX11_THREAD_LOCAL | ||
| #define BOOST_NO_CXX11_DECLTYPE_N3276 | ||
| #define BOOST_NO_CXX11_UNRESTRICTED_UNION | ||
|
|
||
| // C++ 14: | ||
|
|
@@ -238,3 +374,4 @@ | |
|
|
||
| #define BOOST_COMPILER "CodeGear C++ version " BOOST_STRINGIZE(__CODEGEARC__) | ||
|
|
||
| #endif // #if !defined(__clang__) | ||
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm changing this logic to simply
bcbin #346. This makes it easier to match the toolset name used by Boost.Build (in the "versioned" layout).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The toolset used by Boost.Build to build Boost for the Embarcadero C++ clang-based compilers should be 'embarcadero.jam' and not 'borland.jam'.
I think it is very bad if building for the old bcc32 compiler ( although it will fail miserably with current Boost ) should create the exact same library names as building for the clang-based compilers. That is why I chose different names for the Embarcadero C++ clang-based compilers. However I think you are right that there should not be different toolsets based on 32bit or 64bit builds, as no other compiler does that, so I would choose 'embtc' or maybe just 'emb', for the Embarcadero C++ clang-based compilers rather than the bcb32/bcb64 above. But I would not choose the same toolset name as for the old bcc32 compiler, as it will be confusing to the Embarcadero end-user, who may be used to seeing that name refer to the old compiler.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is nowadays (since v10.3.3) a linker warning against this problem: https://blogs.embarcadero.com/issues-mixing-classic-and-clang-objects-linker-warnings-improving-app-stability/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In Embarcadero's home-grown version of Boost 1.68/1.70 their lines are:
I changed this slightly to "bcb32" from "bcb32c", since the Embarcadero C++ clang-based compilers are bcb32c and bcb32x, with the exact same clang-based code in all situations, and the only difference being that bcb32c uses the old bcc32 compiler options while bcb32x uses clang-based compiler options. They created separate names for their Embarcadero C++ clang-based BOOST_LIB_TOOLSET and their old bcc32 BOOST_LIB_TOOLSET. I think that separation should continue. But I agree with you that Boost usually does not create separate BOOST_LIB_TOOLSET names for 32bit and 64bit builds. So I still think that giving a BOOST_LIB_TOOLSET name that is different from the 'bcb' name is the way to go. So I would choose 'embtc', which is the general mnemonic Embarcadero used in their home-grown version of 1.68/1.70 to indicate the clang-based compilers.