"Jody Hagins" <jody-boost-011304@atdesk.com> wrote in message news:20070520104928.342b913e.jody-boost-011304@atdesk.com...
On Sat, 19 May 2007 23:02:44 -0400 "Gennadiy Rozental" <gennadiy.rozental@thomson.com> wrote:
I understand the "BOOST_TEST_MAIN" but the BOOST_TEST_DYN_LINK does not make sense. The link decision is totally independent of the compilation UNLESS the code is being built to be included in a library. This is obviously not the case here, as an executable, not a library, is being built.
This is not true for NT, ergo it's not true in general.
I'll take your word for it... I don't develop for NT. Which begs the issue... why do I now have to conform to a workaround for NT... I've never had to do it before, and if certain systems require workarounds, then they should be transparent to others.
Developers that are USING a library should be insulated from stuff required for other platforms as much as possible. Since everything worked previous to 1.34 without this "NT workaround" it is obviously possible... so my point is, whay did it have to change? It looks, to me, that it was a choice, not a necessity.
For *nix users, this is completely strange, unconventional behavior, not pushed upon them... where before 1.34 they did not even have to worry about it. Again, I'll say... the decision does not make sense to me.
Let me repeat that for a portable development you sometimes are required to do things that are not natural for one particular platform. That said, let's now try to find some way to make you happy ;) I can create a separate target that builds shared library using static library flags. This target will only exist for !NT platforms. Now we just need to decide how to name these 3 targets. From what I see in Jamfile.v2 this new target will have to be named differently from two built now. That means that static and this "like static" shared library will be named differently. Let me know what you think. Gennadiy