Re: [Boost-users] Troubling building Boost for Borland C++ Builder 6

From: Edward Diener (eddielee_at_[hidden])
Date: 2005-07-22 18:00:20

Robert Ramey wrote:
> Edward Diener wrote:
> 
> 
>>Clearly this is a case for a built library to be split up into
>>sub-libraries, so that there would be a built serialization library
>>supporting binary serialization, which would not be dependent on
>>Spirit, and a built serialization library supporting XML
>>serialization, which would be dependent on Spirit. In this case I
>>would be able to build the library that did not depend on Spirit for
>>C++ Builder and I would not care, if I never used XML serialization,
>>whether or not the library that was built to support XML
>>serialization could be built for C++ Builder 6.
> 
> 
> I can sympathize here.  But the serialization library is already split into 
> two libraries.  Combining this with auto-linking turns out to complicate 
> things.  Making into four libraries would be even worse.
> 
> 
>>In the serialization documentation it says that one can build
>>serialization so that it can be used with C++ Builder 6 by
>>downloading the standalone version of Spirit 1.6, installing that,
>>and setting the SPIRIT_ROOT environment variable to the directory
>>where Spirit 1.6 is installed. Despite having done this, any attempt
>>to build serialization for C++ Builder 6 ends with error messages
>>showing that header files for Spirit in the main Boost directory,
>>rather in the Spirit 1.6 directory, are being used in the process to
>>build the serialization library. The error message comes from
>>spirit/core/config.hpp in my Boost 1.32 directory tree that C++
>>Builder 6 is not supported. In the Spirit 1.6 distribution there is
>>no spirit/core/config.h.
> 
> 
>>While I understand that a particular library may not want to support a
>>particular compiler/version because that compiler is deficient in the
>>C++ standard requirments to support that library, I feel that if a
>>library is marked as supporting a compiler/version it should do so.
>>In the case of serialization in Boost 1.32 it is marked as supporting
>>C++ Builder 6 when clearly it does not according to my efforts.
> 
> 
> All I can say it that this has worked from me as well as the testers in our 
> matrix.

I have discovered the reason for the problem. It has to do with the form of 
#include in the Spirit 1.6x headers. The headers erroneously use, in some 
places, the form:

#include "boost/..."

rather than

#include <boost/...>

In the first form C++ Builder, and I believe most compilers, will first look for 
the header file starting from the current directory before it applies the 
directories in its include path(s). Because of this it will find the Spirit 
headers in the Boost 1.32 directory structure before it finds the Spirit headers 
in the alternative Spirit location, since the compilation of serialization is 
being done from the Boost directory root.

I can fix this on my own local copy of Spirit 1.6.2, by changing the erroneous 
form of the headers, and I will tell the Spirit developers about it on their NG. 
I realize it is an older copy of Spirit to go back and fix correctly, but since 
they had fixed this for the latest copy of Spirit, and it is a simple change to 
their headers for the earlier version, I do not think they will mind doing so.

I do not believe that Bcb6 was tested using the SPIRIT_ROOT technique or else 
the test would have shown the same problem which I have discovered.

> 
> I do have a good fix for you though.  You can comment out the xml_*.cpp 
> files in the Jamfile that builds the library.  This will exclude these 
> modules from the library.  This should permit one to build and use all the 
> other types of archives.

OK, but I prefer to fix the Spirit headers locally.

> 
> There is another option as well, for some applications (e.g. those that want 
> to do global optimization) it might be more convenient to skip the library 
> step altogether and just included the *.cpp files for the archives that are 
> to be used.  This seems less attractive to me - but it might be an option 
> for some people.

That is a solution but it is as unattractive to me as it is to you.