From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2007-05-20 23:41:21
"Jody Hagins" <jody-boost-011304_at_[hidden]> wrote in message
> On Sat, 19 May 2007 23:02:44 -0400
> "Gennadiy Rozental" <gennadiy.rozental_at_[hidden]> 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
Let me know what you think.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk