Support for building OWLNext with the Clang-based compilers in Embarcadero C++Builder/RAD Studio is only partly implemented. Full support should be added and backported to supported release branches.
Bugs: #405
Discussion: Issue building 6.40
Discussion: Delphi & C++Builder FREE Community Editions Updated to Version 10.4.2 Are Now Available!
Discussion: Delphi & C++Builder FREE Community Editions Updated to Version 10.4.2 Are Now Available!
Discussion: OwlMaker and RAD Studio XE7
Discussion: OwlMaker for RAS Studio XE8
Discussion: Unresolved external TNewStreamer move constructor
Discussion: TRichEdit text color
Discussion: Unable to open file 'OWL-6.43-C720-X86-S.LIB'
Discussion: Unable to open file 'OWL-6.43-C720-X86-S.LIB'
Discussion: Owlmaker missing threading option: clang + owl 6.44 + vcl mode
Discussion: Help needed: Support for 64-bit C++Builder (BCC64)
Discussion: Help needed: Support for 64-bit C++Builder (BCC64)
Discussion: Clang, VCL, Unicode and OWLNext7
Discussion: Clang, VCL, Unicode and OWLNext7
Discussion: Clang, VCL, Unicode and OWLNext7
Discussion: Clang, VCL, Unicode and OWLNext7
Discussion: Trunk now compiles with BCC64
Discussion: OWLNext 6.44 Beta and work on OCFNext
Discussion: Embarcadero RAD Studio 10.2 Tokyo
Discussion: Embarcadero RAD Studio 10.1 Berin
Anonymous
Since 6.40.2 the core has built using the "source/owlcore/CBXE3" project file for 64-bit C++Builder (BCC64 in XE3 or later). Similar project files exists for the extension libraries ("source/*/CBXE3"). However, compilation errors in OCFNext and OWLExt remain.
Support for 64-bit C++Builder XE8 was added in OWLMaker Build 3183, allowing 6.40 and later to be built in 64-bit mode using this compiler.
Originally, only the static-ANSI configurations Debug and Release were provided in the project files, but support for more build modes (OWL 5 compatibility mode and Unicode) has been added on the trunk [r3193] [r3191].
TODO
It would be helpful if anyone with access to C++Builder/RAD Studio could help with the following:
Related
Commit: [r3191]
Commit: [r3193]
Last edit: Vidar Hasfjord 2015-06-06
Diff:
Relating point #1:
I've opened the C:\OWL643\source\owlcore\CBXE3\owl.cbproj in C++Builder XE (relased in 2010) whithout problems. The Project manager shows the 'Win64' platform and declares it 'Unknown platform'. I will repeat the test on Berlin later.
Hi Sebastian, the 6.43 version of the MSBuild project file, "branches/643/source/owlcore/CBXE3/owl.cbproj", is the unmodified version. My modifications were made to the 7 version of the file, "trunk/source/owlcore/CB/owl.cbproj". Hence, point 1 above relates to the latter file.
In addition to be able to open the file in the IDE, it is of course interesting to know
Yes, I've just noticed.
I've downloaded the https://sourceforge.net/p/owlnext/code/HEAD/tree/trunk/source/owlcore/CB/owl.cbproj
and repited the test in XE. No problem to open it.
I've just saved and the CBuilder XE deleted some nodes related Win64 and OSX.
I will repeat the test on Berlin in a few hours.
More info:
The .cbproj file generated after opening and saving with C++Builder XE keeped the nodes:
at the <PropertyGroup> node,
but it deleted the nodes:
Last edit: Sebastian Ledesma 2016-09-12
That's unfortunate, but we can alert the users about this — if you need to change the project file, then save a copy, don't overwrite it. Unless you can come up with a solution that preserves the relevant PropertyGroup nodes, of course.
Edit: On second thought, I guess a better solution is to properly define configurations within the IDE for OWL5_COMPAT mode and Unicode, and all combinations thereof. Then you can build all those configurations from the IDE too. Today, I presume, the IDE can only build with the default setting of my hand-crafted variables (OWLNextCompatibility and OWLNextUnicode). With explicit configurations defined for all combinations of build modes, OWLMaker can just pass the requested configuration to MSBuild through the Config and Platform parameters that the IDE also understands.
Of course, there are quite a few possible combinations so it will require manually setting up a whole lot of configurations in the IDE. But I think it is the way to go, if you are up to it. An alternative and perhaps more efficient way to do this would be to manually edit the project file in a text editor.
All combinations of compatibility mode (OWLNext, OWL), debug mode (debug, release), character set mode (ANSI, Unicode) and link mode (static, dynamic) comes to 16 configurations. If you want to include support for single-threaded RTL, it doubles to 32 configurations. That is for each platform. As for naming all these configurations, I suggest using the suffix in our library naming convention, e.g. "5dtui" (OWL5_COMPAT, debug, multi-threaded RTL, Unicode, dynamic linking).
Note that you can use configuration inheritance and option sets (called style sheets in Borland C++ and property sheets in Visual Studio), to combine build mode settings into configurations. Also, the common settings for all configurations can be made in the Base configuration, which is inherited by all configurations. With that, updating settings pertaining to a particular build mode is piece-of-cake, since you can edit the Base configuration or the relevant option set, rather than make the same change in all configurations manually. See Build Configurations Overview.
Last edit: Vidar Hasfjord 2016-09-12
Here is the owl.cbroj after just opening and saving with C++Builder Berlin.
It seems that it deletes the conditional nodes not officialy supported.
In example: I didnt install OSX32 platform and it deleted the nodes for OSX32, in other hand it added the nodes for iOS32 and Android.
That confirms the hand-crafted changes are destroyed after an overwrite by the IDE — if not entirely, at least to the degree of being nonfunctional. So I think the best route to take is to create explicit configurations for all combinations of supported build modes, as described in my earlier post.
Still, there is one issue left unsolved, even with explicit configurations for the build modes, and that is build setup. Build setup requires a pre-build event that calls "update_version_header.bat". The problem is that OWLMaker needs to be able to turn that event on or off, depending on the setting "Perform build setup" in the wizard. Of course, you can add separate configurations with build setup and no build setup, but that doubles the number of configurations again.
Perhaps it can be solved by using a MSBuild user-defined property (variable) in a clever way, since as you have shown, the RAD Studio IDE preserves the user-defined properties (in the top PropertyGroup), as well as their usage in the defintion of other properties (e.g. IntermediateOutput uses OWLNextUnicode in its definition). So maybe this works:
Otherwise, you can just execute the pre-build step unconditionally, and we'll disable the option to turn off "Perform build setup" in OWLMaker for the affected toolsets. Performing unnecessary setup does no harm (it will just report that the version header is already up to date).
Last edit: Vidar Hasfjord 2016-09-13
I'm just catching up with the current OWLMaker and MSBuild and perhaps we can pass the OWL5_COMPAT as a command line parameter.
Something like this:
http://stackoverflow.com/questions/166474/msbuild-set-a-specific-preprocessor-define-in-the-command-line
I was meaning to change the
and add the $(OWLNextCompatibility) macro to the <Defines> node.
Then invoke the MSBuild with
msbuild /p:OWLNextCompatibility="OWL5_COMPAT"
for building OWLNext with the OWL5 API.
Yes, we can pass MSBuild properties as parameters to the MSBuild command. That's what OWLMaker already does. You can see the generated command lines on the final page in the wizard. E.g. here is the command line generated by OWLMaker for the default release build:
The two properties Config and Platform are standard for MSBuild and recognised by RAD Studio. So setting these to the requested configuration and platform will work, provided the requested configuration and platform is defined within the project file. This is my suggested ideal solution.
However, since I did not have access to RAD Studio (my trial had run out), I instead created the additional properties and hand-crafted changes to customise the existing configurations within the project file. As you can see, these additional properties are also passed the same way as the standard properties.
Yes, your use of the OWLNextCompatibility property within the Defines tag should work, and as you have shown, this use should be preserved by RAD Studio.
However, this solution, like my current solution, is not much good for IDE users. So the likelihood is that the user will modify the project file as desired, and in the process destroy the customisations that OWLMaker depend on. So it may not be much better than the current solutions with an added warning not to overwrite the project file.
Here is the OWL.cbproj with the 'Debug Unicode' and 'Release Unicode' build configurations added.
Both were defined as inherited from standard 'Debug' and 'Release' build configuration.
Looks good. I recommend explicit configurations for compatibility mode as well. Then it is straight forward to correctly set the target file name for the configuration.
Your assumption that OWLNextCompatibility is defined as "OWL5_COMPAT" (or "") in the Define tag, is not compatible with its use in the IntermediateOutputDir tag, as well in the generation of the target name in the PostBuildEvent tag, where it is assumed to be "5" (or ""). Creating an explicit configuration avoids this complexity.
Here is the version with explicit configurations:
Debug
Debug_Unicode
Debug_OWL5COMPAT
Debug_OWL5COMPAT_Unicode
Release
Release_Unicode
Release_OWL5_COMPAT
Release_OWL5_COMPAT_Unicode
Last edit: Sebastian Ledesma 2016-09-13
I think that by adding the Win32 platform we can use this very OWL.cbproj to support the Embarcadero Free C++ Compiler: https://sourceforge.net/p/owlnext/feature-requests/100/
Hi Sebastian, it is encouraging to have you working on this! It is the most obvious area of OWLNext where my capacitity for support is limited, since I am not an Embarcadero customer, and hence do not have access to C++Builder/RAD Studio. I have tried to ask Embarcadero for a license in support of OWLNext, but I had no reply. And donations, although much appreciated, have been too few and small for me to feel comfortable investing in a license and the time and effort needed to support these products in OWLNext. Still, I have devoted a fair amount of time to it, as you know.
Here is my advice on how to proceed on this task:
Regarding point 2, I came up with a scheme for Owlet (which uses a Visual Studio MSBuild project file to build). As mentioned in an earlier post, I simply use the suffix of our naming convention. This naming scheme is predictable and easy to use and maintain in OWLMaker since it follows our naming convention. And it allows some clever use of the Config property, as I will explain.
Regarding point 4, in Owlet, with the establised naming convention for the configurations, I can use the property Configuration to define the target name (Configuration Properties | General | Target Name). See "branches/owlet/build/Owlet.vcxproj".I did a quick search on the net, but unfortunately, it seems RAD Studio does not support setting the target name. It seems it is fixed to the project file name. If that is so, you have to use a post-build event to rename it. This is what my current solution does (see PostBuildEvent in the project file).
Regarding point 6, one solution is to rely on OWLMaker to pass the correct version of the library, like my current solution does. However that does not work when building from the IDE. You can set a default in the top PropertyGroup to alleviate the problem. I recommend using "0.0" since it is surely not going to be properly maintained to reflect the real version number. Jogy used to do that across many files, but that was a chore. Instead, we can tell the IDE user to set it. An alternative solution is to make a script that modifies the MSBuild project files as part of the build commands generated by OWLMaker, before invoking MSBuild.
Finally, since I rely on these MSBuild scripts now to do build testing, it would be very helpful if precompiled headers and parallell (multi-processor) compilation, if available, was properly enabled to speed up the build as much as possible. Users would appreciate that too, I am sure.
Related
Wiki: OWLNext_naming_convention
Note that the Free C++ Compiler does not come with the MSBuild tool. It only comes with "make", that's why my preliminary work on supporting this compiler provides a make file for this setup.
HI:
1 - I think that the relevant configurations are:
Debug, Debug_Unicode, Release, Release_Unicode for OWLNext 6.4x and 7.x. Not sure in backport it also to 6.35.x
We dont use the OWL5_COMPAT mode, instead we prefer to use:
where it's needed. We prefer this way to do the migration path from older versions to newers.
In the other hand i will try to keep the OWL5_COMPAT for compatibility. So for me there is no problem in adding also the Debug_OWL5COMPAT, Debug_OWL5COMPAT_Unicode, Release_OWL5COMPAT, Release_OWL5COMPAT_Unicode configurations.
2 - The OWLNext naming conventions has worked well all this time. My idea is to keep using it. I'm not sure right now if it's needed a specific suffix to indicate a Clang compiled library.
3 - I need a OWLMaker updated for that :)
I think that I can recompile it using C++Builder, but for that I need to move to OWL7.
4, 5, y 6 Agree.
7 Our main application (AIRE.EXE) uses OCFNext, so support for OCFNext it's a must.
The OWLext is small compared to OWLNext so it can be included in the task
8 As we are using 6.30.12+ on production we intend to move to 6.4x. We did a migration of a small project (3 OWLNext files for the app, plus12 shared files with others modules) with sucess. In the way we learned ther process, so problably we avoid the 6.35 step to go directly to 6.4x
Hi Sebastian, great, sounds like you are on top of this. Good!
Regarding OCFNext and 6.43, note that there are two bug tickets resolved and pending on the trunk (7). You may also find it useful to browse all tickets with the OCF label. There are many open and unresolved issues.
We don't. The updated naming convention now uses the "c" prefix on the compiler part of the library name to denote that the library is built with a Clang-based Embarcadero compiler, e.g. "owl-7.0.0-c720-x86-dt".
Note that there is no problem in installing many working copies from different branches in the code repository. The source code, including the examples, no longer depends on the setting of environment variable OWLROOT. And OWLMaker will build any version you point it to on the initial wizard page. I have these working copies checked out with Subversion (TortoiseSVN), allowing me to work on them all concurrently, do merging, etc.
Last edit: Vidar Hasfjord 2016-09-13
As I know Codeguard it's not compatible with CLang. No problem in support single/multi/VCL threaded.
Ok.
Last edit: Sebastian Ledesma 2016-09-14
Yes, i've noticed. It allows to more easily try several versions.