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