Yesterday we released RAD Studio 10.2.3, and we have a number of new C++Builder features. I wrote earlier about rename refactoring for C++, but today I also want to mention one small but useful one for our power users: a new compiler driver called bcc32x.
It’s a minor addition, but useful.
Table of Contents
Our compilers
In 10.2.3, we ship a number of compilers.
First, our classic compilers: the C++ compilers that users often know as the Borland compiler, bcc32. This is bcc32 for Win32, and bccosx for macOS 32-bit.
Second, our Clang-enhanced compilers, our current generation. These are bcc32c for Win32, bcc64 for Win64, bccaarm for Android, bcciosarm for iOS32, and bcciosarm64 for iOS64. All of these are based on Clang, and extended with our own enhancements. All of these apart from bcc32c support a subset of Clang flags on the command line. bcc32c has a different command-line interface, ie supports a different set of flags: it shares the command line flags with classic bcc32. This is great for backwards compatibility, and creates an excellent upgrade path from classic bcc32 to bcc32c for users building for Win32 and wanting to move forward, but it means that we have an inconsistency: not all our Clang-based compilers support the same command line interface.
This incompatibility makes it difficult to create build scripts or use tools that call the command-line compilers that can target all our modern compilers, or even just all our modern Windows compilers. That different command-line interface for Win32 in the form of bcc32c gets in the way.
Command line consistency
Using the same command line flags for both classic bcc32 and modern bcc32c is very important: it makes it very easy for you to upgrade to the new compiler and still use your existing build scripts or similar, largely unchanged.
But we also want to have a consistent set of command line flags for all our modern compilers.
The answer: a new Win32 compiler driver. The driver is the command line tool: it is the compiler front-end, what you normally think of as the command line compiler (say, bcc32c.exe or bcc64.exe.) This new driver, bcc32x, is identical to bcc32c except it supports the Clang command line flags in common with all our other Clang-enhanced compilers.
It is added in addition to bcc32c. bcc32c is really important and will remain. Apart from the command line flags, the two are identical.
Hooray for consistency!
| Classic compilers | ||||
| Compiler | Platform | C++ standard | Command-line | Notes |
| bccosx | macSO32 | C++98/03 | bcc (classic) | |
| bcc32 | Win32 | C++98/03 | bcc (classic) | Classic ‘Borland’ compiler |
| Clang-enhanced compilers (current generation) | ||||
| Compiler | Platform | C++ standard | Command-line | Notes |
| bcc32c | Win32 | C++11 | bcc (classic) | Upgrade path from the classic compiler |
| bcc32x | Win32 | C++11 | Clang | New in 10.2.3! Same as bcc32c, but the Clang command line |
| bcc64 | Win64 | C++11 | Clang | |
| bcciosarm | iOS32 | C++11 | Clang | |
| bcciosarm64 | iOS64 | C++11 | Clang | |
| bccaarm | Android32 | C++11 | Clang | |
Command lines
bcc32 and bcc32c
bcc32 -O2 -w main.cpp
O2 optimization, show all warnings, build main.cpp.
bcc32x, bcc64, etc
bcc32x -fborland-extensions -O3 -Wall main.cpp
Turns on our language extensions, O3 optimization, show all warnings, build main.cpp.
The -w flag is a great example of a different command line parameter: for the classic command line, it means display all warnings. For the Clang command line, it means suppress all warnings; to display all warnings you need to pass -Wall.
Using one consistent command line between all compilers you use should simplify any command line or external tool usage.
Questions
- Is this the promised C++17 compiler?
- No, not yet. It is coming though!
- Do I need to change anything?
- No. But you can if you want. For example, if you have build scripts or a continuous integration tool that ignores msbuild and calls the compilers directly, and say you’re building for both Win32 and Win64, you can clean up your script or configuration to use very similar or the same usage for both targets.
- Sure about that?
- Very sure. We still ship the classic compiler and having bcc32c compatible with it is very important as an upgrade path.
- Which of the two (bcc32c or bcc32x) does the IDE use?
- Actually, neither. The IDE calls the compiler through a DLL, bypassing the command line flags altogether. The flags it prints out in the Build tab are the equivalent of what it calls in direct code internally.
- Why did you do this?
- Consistency. Now all Clang-enhanced compilers share a compatible set of command-line flags, you can drive them all the same way.
- Okay, but was there some other reason to do this?
- Yes! The specific reason we did this in 10.2.3 is that we added CMake support. That calls our command-line compilers. More on CMake in an upcoming post – it’s very exciting news!