Re: [boost] issue with library build in development tree

From: Rene Rivera (grafik.list_at_[hidden])
Date: 2003-10-28 16:40:00

[2003-10-28] Robert Ramey wrote:

>when I build the test  and filesystem libraries I get the following tree
>
>boost-dir
> bin
>  boost
>   filesystem
>    build
>     libboost_filesystem.lib
>      vc7
>       debug
>        libboost_filesystem.lib
>       release
>        libboost_filesystem.lib
>   test
>    build
>     libboost_prg_exec_monitor.lib
>      vc7
>       debug
>        runtime_link_static
>         theading-multi
>          libboost_prg_exec_monitor.lib
>         threading-muli // note empty directory

Is that really "threading-multi" vs. "threading-muli" (note missing "t") ??

>I have a couple of complaints about this:
>
>a) there are extra empty  threading-multi directories
>This isn't a big problem itself - it just shakes my
>confidence.

Not sure how you get those, as I get only the ones it actually builds things
into.

>b)  The final locations of the libraries seems to
>be a side effect to the jamfile targets chosen.  

Yes, for one good reason... it's the only way to effectively separate
incompatible built binaries from each other.

>Its very hard tor anyone without a pretty good
>knowledge of tools jamfile contents to know where
>the libraries are going to end up.

Very true ;-)

>c) if a jamfile is changed it seems that the libraries
>may well endup in a different place.  This would require
>that any projects taht point to them - e.g. for linking
>would have to be modified.  In my particular case it
>is convenient to use VC IDE to build projects linking
>to prebuilt boost libraries.  If the position of a library
>changes - I have to go back and modify all the VC
>projects that use it.

Another good point :-)

>d) when no target is specified - e.g. runtime static
>its not clear which version of the target is geneated.
>Looking at the above, one can't determine what
>kind of target libboost_filesystem.lib is - multi-threaded
>single threaded etc.

Yep.

>e) one might just move them or link to them from
>some other directory.  That's not that easy as different
>targets have the same name.  Once they are moved
>from the directory hierarchy information will be lost.

Yes that's been a big pain for many people.

>I would prefer that the defined hierarchy not change
>when the jamfile is changed.  This might result in
>some extra levels of directory but it would be
>preferable to the current situation.

It would actually introduce a _large_ number of directory levels to get
something like that. There are many variations that can cause built binaries
to be incompatible and they would all have to be accounted for in such a
scheme.

But to really answer your concerns you should try the new build+install
support. It answers all of your problems. See this post:
http://tinyurl.com/s1ke

HTH.

-- grafik - Don't Assume Anything
-- rrivera (at) acm.org - grafik (at) redshift-software.com
-- 102708583 (at) icq