Boost logo

Boost Users :

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-07-22 16:24:18

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

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.

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.

Robert Ramey

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at