Re: [Adobe-source-devel] Questions on using Boost

[Foster T. B. <fbr...@ad...>]

Hi Jacob,

On 11/10/06 4:09 p, "Sean Parent" <sp...@ad...> wrote:

>> Second, assuming there are no objections to using the adobe/third_party
>> flavor=20
>> of Boost, I have a linking question.  On my system (XP, VC80), for examp=
le,
>> ASL builds the debug filesystem lib named as follows:
>> boost_filesystem-vc80-mt-d-1_33.lib
>> However, including boost/filesystem in my own application triggers an
>> auto_link w/ the following:
>> libboost_filesystem-vc80-mt-sgd-1_33_1.lib
>>=20
>> I do not understand where the discrepancies in naming come from.  Appare=
ntly,
>> the Adobe built lib is intended to be used as a dynamical lib, but I do =
not
>> see a corresponding DLL.  Also, why would the versions differ?
> Hmm - Mat or Foster might be able to answer that one.
> Sean

There are several issues at play here:
    - When compiled with MSVC the Boost libraries will automatically attemp=
t
to link in the built boost library they deem most appropriate based on the
build settings of your application. This 'feature' is the cause of many
headaches as many people do not figure C++ code would affect the dependency
listings sent to the linker, but there you have it. In order to turn this
off, #define BOOST_ALL_NO_LIB=3D1 in your build settings (which we do when
building ASL).
    - The alphabet soup at the end of the a boost library artifact is
intended to describe the settings under which said library was built. When
building using bjam the tags are derived from a procedure called 'rename' i=
n
stage.jam, which is found in boost/tools/build/v2/tools/stage.jam. When the
linker is given its auto-link instruction from the boost C++ sources, the
library name is derived within boost/config/auto_link.hpp. In the former
case bjam attributes (e.g., <link>static) are used to derive the name,
whereas in the latter case the build environment is used. In all likelihood
what is arising is that the built libraries are named according to the bjam
rules, but because we set so many flags and preprocessor defines manually
(not via bjam attributes) the auto_link code is deriving a separate set of
decorations for the name of the library.

All that to say that this could be our bug, in that we should be using the
proper bjamese to get the build settings right, in which case the bjam
library artifacts would match the names as they are derived by
auto_link.hpp. However, I am also under the understanding that bjam does
'reverse lookup' on the build environment, and is capable of deriving all
the necessary bjam attributes based on it. I could be wrong there, or I
could be right but the functionality is not attached to the library tagging
mechanism.

So, in short, the bug could be very difficult to resolve if you would like
to continue using automatic linking (which we do not recommend). If you do
happen to come across the right fix (and it belongs in ASL), we'll gladly
patch our distro and give you all the credit.

Our recommendation would be to #define BOOST_ALL_NO_LIB=3D1 and specify the
libraries to which you would like to link explicitly. It would seem bjam
jibes with such a process, as we have been building ASL this way for many
releases.

Blessings,
Foster


--=20
Foster T. Brereton                  <=E1=BC=B0=CF=87=CE=B8=CF=8D=CF=82><                Romans 3:=
21-26
A d o b e   S o f t w a r e   T e c h n o l o g y   L a b
"What 99 percent of programmers need to know is not how to build components
but how to use them." -- Alexander Stepanov
"Now we have very simple code and the meaning is perfectly clear. Drink the
Kool-Aid" -- Sean Parent