#549 Invalid Boost path causes OWLNext build errors with BCC32 toolset

[Vidar Hasfjord]

If Boost is not installed in the expected location, the OWLNext build will fail with compilation errors, such as errors referring to "std::tr1". For example, this may happen if Boost is not installed, or if the Boost root directory is renamed, deleted or moved. The problem may also occur with later versions of the Embarcadero products that install Boost in a different location.

See [discussion:309917ff36].

[Vidar Hasfjord]

The attached patch is a possible solution. It only sets CG_BOOST_ROOT if not set, and sets it to the new path for compiler version 760 (C++Builder 11).

However, note that this does not work if the path is not the same for all toolset versions and editions detected as BCCVER == 760. If the path is different from 11.0 to 11.3 and/or between the Community Edition and the commercial editions, then we need a way to detect which path is correct. Or, if it is indeterminate, a somewhat dirty solution is to include both paths (this will lead to a warning, but should otherwise not hurt).

Alternatively, we can just generate an error message telling the user to set CG_BOOST_ROOT in this case.

In any case, the patch adds Boost path validation in the Init rule, so the build will not proceed if the Boost root is not properly configured.

Please review and test.

[Vidar Hasfjord]

I have now committed my proposed patch to branches 6.44 [r6484] and 6.36 [r6485].

Note that all versions 11.0-11.3 of Embarcadero RAD Studio/C++Builder Alexandria have COMPVER=760, so the make-files will try to use the new path for all of these, although it may only be correct for 11.3. However, if the root path is incorrect, the make-files will now fail with an error message, telling the user to set CG_BOOST_ROOT correctly.

The CG_BOOST_ROOT can be set as an environment variable and will take effect when OWLMaker (or Command Prompt) is restarted. So, no modification of the make-files is necessary to specify the correct path.

Please review and test. If it looks good, I will release updates 6.44.21 and 6.36.7.

[Ognyan Chernokozhev]

Hi,

I have been testing the changes, and one snag that I hit at the beginning is if the CG_BOOST_ROOT environment variable is ending with a backslash, like this:

CG_BOOST_ROOT=C:\Program Files (x86)\Embarcadero\Studio\22.0\include\boost_1_39_0\

the build fails with errors:

1> Warning W8123: Path 'C:\Program Files (x86)\Embarcadero\Studio\22.0\include\boost_1_39_0"' not found - path ignored in option '-I'
1> animctrl.cpp:
1> Error E2209 C:\Program Files (x86)\Embarcadero\Studio\22.0\include\boost_1_39_0\\boost\tr1\tr1\exception 23: Unable to open include file 'boost/tr1/detail/config_all.hpp'
1> Error E2046 C:\Program Files (x86)\Embarcadero\Studio\22.0\include\boost_1_39_0\\boost\tr1\tr1\exception 27: Bad file name format in include directive
1> Error E2209 C:\Program Files (x86)\Embarcadero\Studio\22.0\include\boost_1_39_0\\boost\tr1\tr1\string 16: Unable to open include file 'boost/tr1/detail/config_all.hpp'
1> Error E2046 C:\Program Files (x86)\Embarcadero\Studio\22.0\include\boost_1_39_0\\boost\tr1\tr1\string 20: Bad file name format in include directive

After removing that backslash, all was working correctly, I tried several cases - with the environment variable pointing to either the default path or to another location, and all work correctly. I also tried with Boost in the default location and no CG_BOOST_ROOT set, and it also gets correctly applied.

[Ognyan Chernokozhev]

I am also adding a small enhancement to the bc.mak files - to output the CG_BOOST_ROOT value, to help with diagnosing issues.

[Vidar Hasfjord]

@jogybl wrote:

I have been testing the changes, and one snag that I hit at the beginning is if the CG_BOOST_ROOT environment variable is ending with a backslash

Thanks for testing! Good catch!

The following additional test in the Init target detects a backslash:

Init: $(INIT_DEPENDENCIES)
   ...
   @if exist "$(CG_BOOST_ROOT)boost\tr1" (@echo. & @echo Error: CG_BOOST_ROOT can not end with a backslash. Make sure CG_BOOST_ROOT is set correctly.) & exit 6

This test should work, although it is somewhat ugly, since you can make it produce a false positive by creating a dummy directory with a subdirectory "boost_1_39_0boost\tr1". But unless you see any problem with this, or anything else problematic, I will commit it.

I am also adding a small enhancement to the bc.mak files - to output the CG_BOOST_ROOT value, to help with diagnosing issues.

Great idea!

[Ognyan Chernokozhev]

This test should work, although it is somewhat ugly, since you can make it produce a false positive by creating a dummy directory with a subdirectory "boost_1_39_0boost\tr1". But unless you see any problem with this, or anything else problematic, I will commit it.

That would be quite the edge case. And it can be seen by the new diagnostic output of the CG_BOOST_ROOT. So, I see no problem with it.

There may be a better way to detect that a value ends with a backslash and to remove it, but I am not sure if it is worth it to pursue. After all, the old C++ Builder compiler should be used only as a temporary measure before updating to Modern C++.

[Vidar Hasfjord]

The additional test in "bc.mak" for invalid trailing backslash in CG_BOOST_ROOT has now been committed for 6.44 [r6489] and 6.36 [r6490].

[Vidar Hasfjord]

@jogybl wrote:

There may be a better way to detect that a value ends with a backslash and to remove it, but I am not sure if it is worth it to pursue.

I explored better ways in conversation with Bing Chat, but we were unable to find a simpler solution. Bing suggested "$(CG_BOOST_ROOT:~-1)" == "\", but such substring expressions are only valid in the batch-syntax for variable expansion "%CG_BOOST_ROOT:~-1%" == "\", which actually works, but only for an external definition of CG_BOOST_ROOT as an environment variable. Unfortunately, the internal make-file value is not seen.

Putting the expression in an external (or inlined) batch-file would work, but is a more complex workaround than my quick and dirty solution. For example, using an inline file ("response file" in Borland terminology):

Init: $(INIT_DEPENDENCIES)
   ...
   @del test.bat & ren &&~
      @set R=$(CG_BOOST_ROOT)
      @if "%R:~-1%" == "\" exit /b 1
~     test.bat & call test.bat & if errorlevel 1 @echo. & @echo Error: CG_BOOST_ROOT can not end with a backslash. Make sure CG_BOOST_ROOT is set correctly. & exit 6

But I don't think anyone wants such horror.

[Vidar Hasfjord]

I just realised that BC++ 5.5 does not use Boost, so the CG_BOOST_ROOT assignment and verification should not apply to this toolset. I've updated the 6.36 branch accordingly [r6524]. This change was merged into the "bc.mak" files for the extension libraries in [r6526].