Re: [boost] boost build output locations

Subject: Re: [boost] boost build output locations
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2009-08-18 01:41:34

Zachary Turner wrote:

> I notice there's some strange asymmetries in the locations that the
> standard boost build process outputs binaries to.  Is there a reason
> for this?  For example, running
> 
> bjam variant=debug,release  address-model=32
> 
> I get the following directory structure:
> 
> bin.v2
> --libs
> ----date_time\build\msvc-9.0
> ------debug
> --------address-model-32
> ----------  boost_date_time-vc90-gd-1_39.dll
> ----------  boost_date_time-vc90-gd-1_39.lib
> ----------link-static
> ------------threading-multi
> --------------  libboost_date_time-vc90-mt-gd-1_39
> 
> Alright there is one asymmetry evident.  The dll version of the
> binaries are in address-model-32, and the static library version of
> the binaries are in address-model-32/link-static/threading-multi.
> Should there be like a link-dynamic and a link-static?  

Because link=shared is the default, it's not added to the path so as
to avoid making them too long when not really needed.

> It makes it 
> much easier to automate linking and building if everything is
> symmetric, because in some compilers (e.g. visual studio) you don't
> have as much control as you do with a makefile.
> 
> So then we take a look at boost::thread
> 
> bin.v2
> --libs
> ----date_time\build\msvc-9.0
> ------debug
> --------address-model-32
> ----------link-static
> ------------threading-multi
> --------------  libboost_thread-vc90-mt-gd-1_39.lib
> ----------threading-multi
> ------------  boost_thread-vc90-mt-gd-1_39.lib
> ------------  boost_thread-vc90-mt-gd-1_39.dll
> 
> This time, the dll versions appeared under
> address-model-32/threading-multi instead of just address-model-32 like
> in date_time.

The boost.thread library, naturally, is always built with threading=multi.
Boost.DateTime is not having such a requirement, so depending on how you
build it might as well be built statically. It appears that you are
building using custom option, because the standard

        bootstrap.bat
        ./bjam

procedure always builds only multi-threaded libraries.

> Am I going crazy and I have a messed up system, or is this just the
> way it is?  Is it easy to change, or would it be undesirable to change
> for some reason?

The current path naming is designed to avoid getting long paths for default
values of properties. I don't think changing it is good idea.

But maybe you can start by explaining *why* you care? The naming of targets
that are placed in stage/lib is stable, why can't you use those?

- Volodya