[boost] "I want everything" should build "out of the box" (on Windows)

18 views
Skip to first unread message

KTC

unread,
Jul 28, 2009, 1:51:36 AM7/28/09
to bo...@lists.boost.org
Users on Microsoft Windows should be able to build boost with
everything, both in terms of all supported variants and all boost
libraries, with a single command to bjam assuming they have all the
optional supporting libraries available.

An user download boost, and want to build all the libraries that require
building go read the Getting Started Guide
<.../getting_started/windows.html#invoke-bjam> and see the after getting
bjam they use the command
bjam --build-dir=build-directory toolset=toolset-name
--build-type=complete stage

So they enter that into the command prompt and see lots of warnings and
notes about missing optional components. The warnings and notes itself
is fine and informative. Actually, it's incomplete as it stand as it
doesn't tell the user about Boost.IOStreams optional component
requirement of bzip2 & zlib headers. Okay, the user go and install all
the optional components the warnings and notes tell them. After
installing Python, ICU (building it first), Expat (building it first),
and MPI (say MS-MPI), they try again. This time with the command becoming
bjam --toolset=... --build-dir=... --build-type=complete -sHAVE_ICU=1
-sICU_PATH="..." -sEXPAT_INCLUDE="..." -sEXPAT_LIBPATH="..."
-sBZIP2_SOURCE="..." -sZLIB_SOURCE="..." stage

Nope, MPI requires modification of user-config.jam or building it on its
own with --with-mpi. Why? No other optional components build that way.
So they look to see how they do that, and does it.

Second attempt and ... nope. New to 1.39 is the errors
error: link=shared together with runtime-link=static is not allowed
error: such property combination is either impossible
error: or too dangerious to be of any use
due to the changes made as a result of
<http://lists.boost.org/Archives/boost/2009/04/150675.php>. (Recently
noted on
<http://groups.google.com/group/boost-list/browse_thread/thread/2a7bd07468b5ffe6>.)
While catching those errors is good, maybe it should be fixed as well
such that it doesn't come up in the first place if someone do a
--build-type=complete with ICU. So now the users have to build
Boost.Regex separately from the rest of the library (after finding how
to pass the link= & runtime-link= options). By the way, at this point I
would like to point out how it's strange that -sHAVE_ICU=1 mean to build
with ICU, but so is -sHAVE_ICU=0 .... :S

And ... nope, even separately Boost.Regex still wouldn't build without
errors. No one told them they need to rename icuin.lib, icuind.lib,
icuind.pdb & icudt.lib from ICU to icui18n.lib, icui18nd.lib,
icui18nd.pdb & icudata.lib respectively.

With Boost.Regex built, we turn to the rest of the library with
--without-regex. After waiting a while, we discover ... nope, Most of
the library is built but not Boost.Graph. Sorry, this time no one told
them they need to change Boost.Graph's Jamfile.v2 file with
"<find-shared-library>expat" to "<find-shared-library>libexpatwMT" and
adding "<define>XML_STATIC".

Boost is great, it's free, it's flexible and I understand it's developed
for free by volunteers, but its "installation" for someone that want
every libraries could be improved. :-)

Regards,

KTC

--
Only two things are infinite,
the Universe and Stupidity.
And I'm not quite sure about the former.
- Albert Einstein

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

OvermindDL1

unread,
Jul 28, 2009, 4:18:35 AM7/28/09
to bo...@lists.boost.org

As direct as all this was, I have to say that I have experienced
*everything* he has, and more. The .bat file I have for building
boost is getting rather large with all the stuff I have it do just to
work-around so many things. I have mentioned a few of those on the
boost lists, multiple times actually, but nothing has come from it.
The build system definitely needs to be cleaned up a bit though, or at
least made more consistent. That Boost.Regex and ICU annoyances took
a bit of time to figure out when I first experienced each of those
errors, and the odd thing, those errors have been propagating through
many version now, and new ones seem to keep popping up, many of which
I have talked about on this list, how to fix it, why it should be
fixed, but no one that has commit privileges has yet done anything.

Boris Schaeling

unread,
Jul 28, 2009, 5:04:15 AM7/28/09
to bo...@lists.boost.org
On Tue, 28 Jul 2009 07:51:36 +0200, KTC <k...@ktchan.info> wrote:

> [...]the library is built but not Boost.Graph. Sorry, this time no one

> told them they need to change Boost.Graph's Jamfile.v2 file with
> "<find-shared-library>expat" to "<find-shared-library>libexpatwMT" and
> adding "<define>XML_STATIC".

I have another question: What exactly does <find-shared-library> do? Does
it automatically define and use a lib target like:

lib xy : : <name>xy <link>shared ;

Once I know what it does I'll add it to the feature reference at
http://www.highscore.de/cpp/boostbuild/index.html#feature_reference
(another attempt to make using bjam and Boost.Build a bit easier).

Boris

John Maddock

unread,
Jul 28, 2009, 5:37:52 AM7/28/09
to bo...@lists.boost.org
>That Boost.Regex and ICU annoyances took
>a bit of time to figure out when I first experienced each of those
>errors, and the odd thing, those errors have been propagating through
>many version now, and new ones seem to keep popping up, many of which
>I have talked about on this list, how to fix it, why it should be
>fixed, but no one that has commit privileges has yet done anything.

Sorry I must have missed that, what's the problem/fix?

Thanks for your patience....

Still catching up yours, John.

Vladimir Prus

unread,
Jul 28, 2009, 6:46:32 AM7/28/09
to bo...@lists.boost.org
KTC wrote:

Do you actually want Boost.MPI? I kinda expect anybody who wants to use
Boost.MPI to already have MPI installed.

Did you file any issues at svn.boost.org? This is the first time I hear about
any expat-related problems whatsoever. This is also the first time I hear
about "renaming" ICU libraries. As for the runtime-link incompatibility,
my impression was that John did not see anything worth fixing there.

- Volodya

Vladimir Prus

unread,
Jul 28, 2009, 7:00:11 AM7/28/09
to bo...@lists.boost.org
Boris Schaeling wrote:

> On Tue, 28 Jul 2009 07:51:36 +0200, KTC <k...@ktchan.info> wrote:
>
>> [...]the library is built but not Boost.Graph. Sorry, this time no one
>> told them they need to change Boost.Graph's Jamfile.v2 file with
>> "<find-shared-library>expat" to "<find-shared-library>libexpatwMT" and
>> adding "<define>XML_STATIC".
>
> I have another question: What exactly does <find-shared-library> do? Does
> it automatically define and use a lib target like:
>
> lib xy : : <name>xy <link>shared ;

It's the other way around, actually. <find-shared-library> instructs to link
against named library, so

<find-shared-library>x

results in

-lx

on linux (and x.lib on windows). 'shared' means to make sure it's actually
shared.

The 'xy' metatarget declaration you shown above essentially gets
<find-shared-library>xy into build properties of every dependency.

HTH,
Volodya

OvermindDL1

unread,
Jul 28, 2009, 8:10:08 AM7/28/09
to bo...@lists.boost.org
On Tue, Jul 28, 2009 at 3:37 AM, John Maddock<jo...@johnmaddock.co.uk> wrote:
>> That Boost.Regex and ICU annoyances took
>> a bit of time to figure out when I first experienced each of those
>> errors, and the odd thing, those errors have been propagating through
>> many version now, and new ones seem to keep popping up, many of which
>> I have talked about on this list, how to fix it, why it should be
>> fixed, but no one that has commit privileges has yet done anything.
>
> Sorry I must have missed that, what's the problem/fix?

The "error: link=shared together with runtime-link=static is not
allowed" problem is the newest problem I have, appeared in recent
versions, prevents us from doing a complete build. The ICU renaming
thing, well, <quick google search>, Ooo, looky, the 2nd result (1st is
the Boost.Regex docs) is one of my old (well, the most recent one)
posts on this exact subject on the boost-users mailing list. :)
http://lists.boost.org/boost-users/2008/12/43214.php
I have made much older posts as well, but google cannot find them it
seems... But yea, ICU version 3 (and they are *well* past that now,
version 3 is really old now) changed the naming convention of their
shared libraries, thus Boost does not link with it without renaming
things. Check that post for what they were.

Christopher Jefferson

unread,
Jul 28, 2009, 8:50:32 AM7/28/09
to bo...@lists.boost.org

Then, why not have boost try to detect MPI, and then build/install
Boost.MPI in that case automatically?

On Mac OS X, MPI is installed as a system library, yet I still have to
document and describe the unusual procedure required to install
boost.MPI to users. This single feature has left us close to dumping
Boost.MPI in favour of another option.

Chris

Juergen Hunold

unread,
Jul 28, 2009, 10:26:10 AM7/28/09
to bo...@lists.boost.org
Hi !

On Tuesday 28 July 2009, Christopher Jefferson wrote:
> On 28 Jul 2009, at 11:46, Vladimir Prus wrote:

> > Do you actually want Boost.MPI? I kinda expect anybody who wants to
> > use
> > Boost.MPI to already have MPI installed.
>
> Then, why not have boost try to detect MPI, and then build/install
> Boost.MPI in that case automatically?

Well, as usual: Patches welcome.
Creating a bulletproof autodetection system is not trivial. And requires
manpower no one has provided yet. But the need is growing since Boost is
getting more dependent on 3rdparty libs/tools like Expat/MPI.

> On Mac OS X, MPI is installed as a system library, yet I still have
> to document and describe the unusual procedure required to install
> boost.MPI to users. This single feature has left us close to dumping
> Boost.MPI in favour of another option.

Well, I just quote Dave: "Just a bunch of sources". Just add them to
your project/IDE/whatever and build the library yourself.
Been there, done that for Boost.Test on Windows.

Yours,

Jürgen
--
* Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für
* voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH
* fax : ++49 511 262926 99 ! Lister Straße 15
* juergen...@ivembh.de ! www.ivembh.de
*
* Geschäftsführer: ! Sitz des Unternehmens: Hannover
* Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965
* PD Dr.-Ing. Alfons Radtke !

OvermindDL1

unread,
Jul 28, 2009, 10:45:23 AM7/28/09
to bo...@lists.boost.org
On Tue, Jul 28, 2009 at 8:26 AM, Juergen Hunold<juergen...@ivembh.de> wrote:
> Hi !
>
> On Tuesday 28 July 2009, Christopher Jefferson wrote:
>> On 28 Jul 2009, at 11:46, Vladimir Prus wrote:
>
>> > Do you actually want Boost.MPI? I kinda expect anybody who wants to
>> > use
>> > Boost.MPI to already have MPI installed.
>>
>> Then, why not have boost try to detect MPI, and then build/install
>> Boost.MPI in that case automatically?
>
> Well, as usual: Patches welcome.
> Creating a bulletproof autodetection system is not trivial. And requires
> manpower no one has provided yet. But the need is growing since Boost is
> getting more dependent on 3rdparty libs/tools like Expat/MPI.

I am curious, I know Expat is an XML parser or something like that,
but if those libraries that use it do not use features like DTD
verification and such, why not just make an XML parser in Spirit2.1,
it is certainly proven to be just about faster then anything else yet
tested.

Also, I have never used an MPI system, but from quick perusing of what
MPI based systems look like, why does Boost.MPI create a full MPI
system instead of just create a glue on top of it? Especially since
all the MPI system I see seem to cost a rather ridiculous amounts of
money? I am probably missing something about the MPI standard though,
but I do not see what from a quick reading that would warrant such
costs I see.

OvermindDL1

unread,
Jul 28, 2009, 10:46:34 AM7/28/09
to bo...@lists.boost.org
On Tue, Jul 28, 2009 at 8:45 AM, OvermindDL1<overm...@gmail.com> wrote:
> Also, I have never used an MPI system, but from quick perusing of what
> MPI based systems look like, why does Boost.MPI create a full MPI
> system instead of just create a glue on top of it?  Especially since
> all the MPI system I see seem to cost a rather ridiculous amounts of
> money?  I am probably missing something about the MPI standard though,
> but I do not see what from a quick reading that would warrant such
> costs I see.
>

why doesn't Boost.MPI create a full MPI*

Christopher Jefferson

unread,
Jul 28, 2009, 10:54:59 AM7/28/09
to bo...@lists.boost.org

On 28 Jul 2009, at 15:46, OvermindDL1 wrote:

> On Tue, Jul 28, 2009 at 8:45 AM, OvermindDL1<overm...@gmail.com>
> wrote:
>> Also, I have never used an MPI system, but from quick perusing of
>> what
>> MPI based systems look like, why does Boost.MPI create a full MPI
>> system instead of just create a glue on top of it? Especially since
>> all the MPI system I see seem to cost a rather ridiculous amounts of
>> money? I am probably missing something about the MPI standard
>> though,
>> but I do not see what from a quick reading that would warrant such
>> costs I see.
>>
>
> why doesn't Boost.MPI create a full MPI*

openMPI ( http://www.open-mpi.org/ ) is free, packaged by default on
Mac OS X, and a quick wc count is about 2M lines of source.
Reimplementing that would be a lot of work, although it might be easy
to do on top of asio.

Chris

OvermindDL1

unread,
Jul 28, 2009, 11:31:52 AM7/28/09
to bo...@lists.boost.org
On Tue, Jul 28, 2009 at 8:54 AM, Christopher
Jefferson<ch...@bubblescope.net> wrote:
>
> On 28 Jul 2009, at 15:46, OvermindDL1 wrote:
>
>> On Tue, Jul 28, 2009 at 8:45 AM, OvermindDL1<overm...@gmail.com> wrote:
>>>
>>> Also, I have never used an MPI system, but from quick perusing of what
>>> MPI based systems look like, why does Boost.MPI create a full MPI
>>> system instead of just create a glue on top of it?  Especially since
>>> all the MPI system I see seem to cost a rather ridiculous amounts of
>>> money?  I am probably missing something about the MPI standard though,
>>> but I do not see what from a quick reading that would warrant such
>>> costs I see.
>>>
>>
>> why doesn't Boost.MPI create a full MPI*
>
> openMPI ( http://www.open-mpi.org/ ) is free, packaged by default on Mac OS
> X, and a quick wc count is about 2M lines of source. Reimplementing that
> would be a lot of work, although it might be easy to do on top of asio.

The main platform I have to work on is Windows, and I had seen that
before but disregarded it since it had no Windows support. However, I
just checked, it looks like Windows support was *just* added (version
1.3.3, the current version, 1.3.4 is in progress), fascinating.
Still, a completely in-boost option would allow for all the template
magic everyone here knows, thus it could become higher performant then
any other MPI library out. Possible incentive anyway. :)

What about expat though, why not use something built-in?

Vladimir Prus

unread,
Jul 28, 2009, 11:33:23 AM7/28/09
to bo...@lists.boost.org
Christopher Jefferson wrote:

Just to clarify -- the procedure is putting one line in user-config.jam,
most likely just:

using mpi ;

? It's also documented at
http://www.boost.org/doc/libs/1_39_0/doc/html/mpi/getting_started.html#mpi.config

If you are saying that the above does not work, can you file an issue? If you
are saying that the above should be automated, can you file an issue as well?

- Volodya

Doug Gregor

unread,
Jul 28, 2009, 11:48:56 AM7/28/09
to bo...@lists.boost.org
On Tue, Jul 28, 2009 at 8:31 AM, OvermindDL1<overm...@gmail.com> wrote:
> The main platform I have to work on is Windows, and I had seen that
> before but disregarded it since it had no Windows support.  However, I
> just checked, it looks like Windows support was *just* added (version
> 1.3.3, the current version, 1.3.4 is in progress), fascinating.

MPICH2 and Microsoft's MS-MPI also provide MPI for Windows.

> Still, a completely in-boost option would allow for all the template
> magic everyone here knows, thus it could become higher performant then
> any other MPI library out.  Possible incentive anyway.  :)

A completely in-Boost option is unlikely to ever perform as well as
any of the aforementioned MPI implementations. Each of these
implementations has had many man-years of optimization to extract the
best performance out of today's networking hardware. Even if we
managed to provide comparable performance for some common platform
(say, TCP on Windows), we're certainly not going to be able to compete
with vendor-optimized implementations for more specialized,
high-performance networking hardware.

- Doug

OvermindDL1

unread,
Jul 28, 2009, 11:51:46 AM7/28/09
to bo...@lists.boost.org
On Tue, Jul 28, 2009 at 9:48 AM, Doug Gregor<doug....@gmail.com> wrote:
> On Tue, Jul 28, 2009 at 8:31 AM, OvermindDL1<overm...@gmail.com> wrote:
>> The main platform I have to work on is Windows, and I had seen that
>> before but disregarded it since it had no Windows support.  However, I
>> just checked, it looks like Windows support was *just* added (version
>> 1.3.3, the current version, 1.3.4 is in progress), fascinating.
>
> MPICH2 and Microsoft's MS-MPI also provide MPI for Windows.
>
>> Still, a completely in-boost option would allow for all the template
>> magic everyone here knows, thus it could become higher performant then
>> any other MPI library out.  Possible incentive anyway.  :)
>
> A completely in-Boost option is unlikely to ever perform as well as
> any of the aforementioned MPI implementations. Each of these
> implementations has had many man-years of optimization to extract the
> best performance out of today's networking hardware. Even if we
> managed to provide comparable performance for some common platform
> (say, TCP on Windows), we're certainly not going to be able to compete
> with vendor-optimized implementations for more specialized,
> high-performance networking hardware.

Good point, I had not read about that. That is part of the possibly
unstated info I was expecting, thanks.

John Phillips

unread,
Jul 28, 2009, 11:57:21 AM7/28/09
to bo...@lists.boost.org
OvermindDL1 wrote:
> On Tue, Jul 28, 2009 at 8:45 AM, OvermindDL1<overm...@gmail.com> wrote:
>> Also, I have never used an MPI system, but from quick perusing of what
>> MPI based systems look like, why does Boost.MPI create a full MPI
>> system instead of just create a glue on top of it? Especially since
>> all the MPI system I see seem to cost a rather ridiculous amounts of
>> money? I am probably missing something about the MPI standard though,
>> but I do not see what from a quick reading that would warrant such
>> costs I see.
>>
>
> why doesn't Boost.MPI create a full MPI*


Christopher's answer is the basic reason, but there are some other
facets.

First, the MPI specification is big. It is documented at the MPI
Forum, and is being revised as we speak. You can read the MPI 2.1
specification documents on line, or buy the 608 page book. Meetings on
2.2 and 3.0 are currently ongoing.

http://www.mpi-forum.org/docs/docs.html

Second is that to be useful the implementations have to be carefully
tuned and tested. Some of the comercial packages simplify this by being
very platform dependent. A boost implementation would not want to do
that, and so the implementation gets harder. However, MPI is used for
ultra high performance codes, so even a few percent performance
difference is reason for a user to choose something else. Boost doesn't
have the testing resources to play in this game.

Third, there are a few widely used and high quality open source
packages already available. OpenMPI is the best known and most modern
but others include LamMPI, LaMPI, MPICH and more.Many installations are
locked in to certain systems because they have gone through the
extensive process of installing, tuning and getting to know one
implementation. You would have to supply a lot of value to get them to
change. Boost.MPI is intentionally designed to be package agnostic.
Whatever the installation chooses, Boost.MPI should work with it.

Fourth, MPI includes Fortran and C APIs, as well as a C++ API that is
different from what Boost.MPI provides. To make a useful version, these
would have to be included. Now is a particularly bad time to start the
C++ part of this work, however. News from the MPI Forum is that the
members of the forum think Boost.MPI is a far better C++ interface than
the one they provided. They have also noticed that Boost.MPI uses the C
bindings under the hood and not the C++ bindings. This combination has
them considering first depricating and then removing the C++ bindings
from the MPI specification in favor of telling people to look to
libraries like Boost.MPI.

In all, I just don't think trying to implement the underlying MPI as
part of boost is a great choice. Maybe you could do it and convince me
I'm wrong, but I think there are better uses for your time. (Which might
include contributing to one of the existing MPI packages.)

John

Kenny Riddile

unread,
Jul 28, 2009, 12:26:23 PM7/28/09
to bo...@lists.boost.org

I'm just looking forward to the day when the current CMake support
exposes all of this optional functionality (variants, zlib, bzip2, etc.)
as CMake variables that I can happily configure via the CMake gui, push
a button, and build exactly what I want. For some reason, CMake seems
much more intuitive to me, both in syntax and structure, than using bjam.

Vladimir Prus

unread,
Jul 28, 2009, 12:36:35 PM7/28/09
to bo...@lists.boost.org
Kenny Riddile wrote:

>> Boost is great, it's free, it's flexible and I understand it's developed
>> for free by volunteers, but its "installation" for someone that want
>> every libraries could be improved. :-)
>>
>> Regards,
>>
>> KTC
>>
>
> I'm just looking forward to the day when the current CMake support
> exposes all of this optional functionality (variants, zlib, bzip2, etc.)
> as CMake variables that I can happily configure via the CMake gui,

Are you suggesting that a UI where you see all configuration variables
immediately, and can tweak them, is a good idea?

- Volodya

Kenny Riddile

unread,
Jul 28, 2009, 12:39:17 PM7/28/09
to bo...@lists.boost.org
Do I sense some sarcasm? :)

Vladimir Prus

unread,
Jul 28, 2009, 12:43:33 PM7/28/09
to bo...@lists.boost.org
Kenny Riddile wrote:

>> Are you suggesting that a UI where you see all configuration variables
>> immediately, and can tweak them, is a good idea?

> Do I sense some sarcasm? :)

There was none intended -- I actually wanted to know the answer to that question.
In part, because you specifically mentioned the gui as good thing, so I want
to find out *what* is attractive exactly.

There's of course hidden agenda somewhere there, but it does not affect genuinity
of the question.

Kenny Riddile

unread,
Jul 28, 2009, 1:11:19 PM7/28/09
to bo...@lists.boost.org
Oh, then yes, I am unequivocally saying that is a good thing, especially
when the GUI runs on all major platforms and has fairly intuitive
command-line alternatives to fall back on. Just as in programming,
having a good interface prevents confusion and misuse. A GUI has the
ability to make it immediately clear which variables are available and
which values are valid for each variable. Doing that without a GUI
usually requires reading through separate textual documentation and
piecing together the information you need.

Vladimir Prus

unread,
Jul 28, 2009, 1:14:57 PM7/28/09
to bo...@lists.boost.org
Kenny Riddile wrote:

> Vladimir Prus wrote:
>> Kenny Riddile wrote:
>>
>>>> Are you suggesting that a UI where you see all configuration variables
>>>> immediately, and can tweak them, is a good idea?
>>
>>> Do I sense some sarcasm? :)
>>
>> There was none intended -- I actually wanted to know the answer to that question.
>> In part, because you specifically mentioned the gui as good thing, so I want
>> to find out *what* is attractive exactly.
>>
>> There's of course hidden agenda somewhere there, but it does not affect genuinity
>> of the question.
>>

> Oh, then yes, I am unequivocally saying that is a good thing, especially
> when the GUI runs on all major platforms and has fairly intuitive
> command-line alternatives to fall back on. Just as in programming,
> having a good interface prevents confusion and misuse. A GUI has the
> ability to make it immediately clear which variables are available and
> which values are valid for each variable. Doing that without a GUI
> usually requires reading through separate textual documentation and
> piecing together the information you need.

Noted, thanks!

troy d. straszheim

unread,
Jul 28, 2009, 3:50:36 PM7/28/09
to bo...@lists.boost.org
Kenny Riddile wrote:
>
> I'm just looking forward to the day when the current CMake support
> exposes all of this optional functionality (variants, zlib, bzip2, etc.)
> as CMake variables that I can happily configure via the CMake gui, push
> a button, and build exactly what I want.

AFAIK it does already. You could join the boost-cmake list:

http://lists.boost.org/mailman/listinfo.cgi/boost-cmake

-t

Kenny Riddile

unread,
Jul 28, 2009, 4:51:27 PM7/28/09
to bo...@lists.boost.org
After some digging in the current CMake scripts, I see that in the case
of IOStreams, it searches in certain standard locations for both zlib
and bzip2 and automatically adds support for them if they are found.
This isn't quite what I was talking about above, but I guess that's a
discussion for the CMake list.

John Maddock

unread,
Jul 29, 2009, 6:32:15 AM7/29/09
to bo...@lists.boost.org
>> Sorry I must have missed that, what's the problem/fix?
>
> The "error: link=shared together with runtime-link=static is not
> allowed" problem is the newest problem I have, appeared in recent
> versions, prevents us from doing a complete build.

You simply can not mix dll's with the static runtime - doing so will in
almost all circumstances cause your application to crash.

> The ICU renaming
> thing, well, <quick google search>, Ooo, looky, the 2nd result (1st is
> the Boost.Regex docs) is one of my old (well, the most recent one)
> posts on this exact subject on the boost-users mailing list. :)
> http://lists.boost.org/boost-users/2008/12/43214.php
> I have made much older posts as well, but google cannot find them it
> seems... But yea, ICU version 3 (and they are *well* past that now,
> version 3 is really old now) changed the naming convention of their
> shared libraries, thus Boost does not link with it without renaming
> things. Check that post for what they were.

Well... As of ICU-4.2, the names of the libraries are documented here:
http://userguide.icu-project.org/icufaq#TOC-How-do-I-install-the-binary-version
and match what the Jamfile assumes (and what I downloaded in the binary
package), this information:
http://source.icu-project.org/repos/icu/icu/tags/release-4-2-1/readme.html#HowToPackage
also uses the same filenames, for example icuin.lib/dll and not
icui18n.lib/dll.

Still missing something yours, John.

OvermindDL1

unread,
Jul 29, 2009, 7:16:23 AM7/29/09
to bo...@lists.boost.org
On Wed, Jul 29, 2009 at 4:32 AM, John Maddock<jo...@johnmaddock.co.uk> wrote:
>>> Sorry I must have missed that, what's the problem/fix?
>>
>> The "error: link=shared together with runtime-link=static is not
>> allowed" problem is the newest problem I have, appeared in recent
>> versions, prevents us from doing a complete build.
>
> You simply can not mix dll's with the static runtime - doing so will in
> almost all circumstances cause your application to crash.
>
>> The ICU renaming
>> thing, well, <quick google search>, Ooo, looky, the 2nd result (1st is
>> the Boost.Regex docs) is one of my old (well, the most recent one)
>> posts on this exact subject on the boost-users mailing list.  :)
>> http://lists.boost.org/boost-users/2008/12/43214.php
>> I have made much older posts as well, but google cannot find them it
>> seems...  But yea, ICU version 3 (and they are *well* past that now,
>> version 3 is really old now) changed the naming convention of their
>> shared libraries, thus Boost does not link with it without renaming
>> things.  Check that post for what they were.
>
> Well... As of ICU-4.2, the names of the libraries are documented here:
> http://userguide.icu-project.org/icufaq#TOC-How-do-I-install-the-binary-version
> and match what the Jamfile assumes (and what I downloaded in the binary
> package), this information:
> http://source.icu-project.org/repos/icu/icu/tags/release-4-2-1/readme.html#HowToPackage
> also uses the same filenames, for example icuin.lib/dll and not
> icui18n.lib/dll.

The version of ICU I have is icu4c-3_8-src.zip, so I am not sure if
that is version 4, or 3.8, or what... Let me hunt for a readme, ah,
so it is 3.8. Well, in the windows version at least of 3.8, the
libraries had those different names. I apparently last built that on
October 18th, 2007, so yea, a bit old by now. I will rebuild with the
latest ICU soon to verify the names are correct again.

OvermindDL1

unread,
Jul 29, 2009, 7:17:57 AM7/29/09
to bo...@lists.boost.org
On Wed, Jul 29, 2009 at 5:16 AM, OvermindDL1<overm...@gmail.com> wrote:
> The version of ICU I have is icu4c-3_8-src.zip, so I am not sure if
> that is version 4, or 3.8, or what...  Let me hunt for a readme, ah,
> so it is 3.8.  Well, in the windows version at least of 3.8, the
> libraries had those different names.  I apparently last built that on
> October 18th, 2007, so yea, a bit old by now.  I will rebuild with the
> latest ICU soon to verify the names are correct again.

Er, correction, that was my old directory in a backup area, the
version I am using right now is 4.0, last compiled on 12/12/08, so it
still had those different names. I will try the latest however.

OvermindDL1

unread,
Jul 29, 2009, 7:54:00 AM7/29/09
to bo...@lists.boost.org
On Wed, Jul 29, 2009 at 5:17 AM, OvermindDL1<overm...@gmail.com> wrote:
> On Wed, Jul 29, 2009 at 5:16 AM, OvermindDL1<overm...@gmail.com> wrote:
>> The version of ICU I have is icu4c-3_8-src.zip, so I am not sure if
>> that is version 4, or 3.8, or what...  Let me hunt for a readme, ah,
>> so it is 3.8.  Well, in the windows version at least of 3.8, the
>> libraries had those different names.  I apparently last built that on
>> October 18th, 2007, so yea, a bit old by now.  I will rebuild with the
>> latest ICU soon to verify the names are correct again.
>
> Er, correction, that was my old directory in a backup area, the
> version I am using right now is 4.0, last compiled on 12/12/08, so it
> still had those different names.  I will try the latest however.
>

Okay, so I downloaded the latest 4.2.1, here are all the libs it
dumped into the lib directory:
icudt.lib
icuin.lib
icuind.lib
icuio.lib
icuiod.lib
icule.lib
iculed.lib
iculx.lib
iculxd.lib
icutest.lib
icutestd.lib
icutu.lib
icutud.lib
icuuc.lib
icuucd.lib

So it looks like it is fixed now. But on my old versions, they build
files with 18 in the name, I checked the solutions and they still do.
Well, that problem no longer exists then, but I did battle with it for
over 2 years there. :p

Christopher Jefferson

unread,
Jul 29, 2009, 8:07:10 AM7/29/09
to bo...@lists.boost.org

I'll file an issue.

The problem I had is that most people don't have a user-config.jam,
and most libraries don't require them. It seems strange to many people
they have to keep a file around in their home directory for building
boost.

Chris

John Maddock

unread,
Jul 29, 2009, 8:08:28 AM7/29/09
to bo...@lists.boost.org
>So it looks like it is fixed now. But on my old versions, they build
>files with 18 in the name, I checked the solutions and they still do.

If you can give me a list of the alternative names, I can
(probably/hopefully!) add them to the names that get searched for.

John.

Vladimir Prus

unread,
Jul 29, 2009, 8:14:48 AM7/29/09
to bo...@lists.boost.org
Christopher Jefferson wrote:

>> If you are saying that the above does not work, can you file an
>> issue? If you
>> are saying that the above should be automated, can you file an issue
>> as well?
>
> I'll file an issue.
>
> The problem I had is that most people don't have a user-config.jam,
> and most libraries don't require them. It seems strange to many people
> they have to keep a file around in their home directory for building
> boost.

You can create a file named project-config.jam in Boost's source directory, too.

I personally find that putting configuration details into a file is superior
approach compared to zillion of options or environment variables. Say, if you
build a project with automake with zillion of configure options, those options
are put directly in Makefile, in your build dir, so if you remove your build tree,
you have to re-figure those options next time you build.

In fact, this is a flaw shared by CMake -- if you configure some project as:

cmake -Dfoo=blah -DBOOST_ROOT=whatever ../src

it helpfully puts those options into the cache file. Unfortunately, when the
configure magic confuses itself (which does happen), your only solution is to
remove the cache, and then you need to recall and pass the same options again.

- Volodya

OvermindDL1

unread,
Jul 29, 2009, 8:16:02 AM7/29/09
to bo...@lists.boost.org

I looked through the old solution and it looks like it is just these two:
icui18n.lib
icui18nd.lib

The original files they reference are the same name, but no 18 in it.

Dmitry Goncharov

unread,
Jul 29, 2009, 9:41:35 AM7/29/09
to bo...@lists.boost.org
There is a restriction that shared and static versions of
libunit_test_framework are not interchangeable.
This makes it difficult to ship unit tests since the author of a unit
test cannot predict what type of libunit_test_framework (shared or
static) the user has on their machine.

Are there plans to get rid of this restriction?

BR, Dmitry

Doug Gregor

unread,
Jul 29, 2009, 11:13:28 AM7/29/09
to bo...@lists.boost.org
On Wed, Jul 29, 2009 at 5:14 AM, Vladimir Prus<vlad...@codesourcery.com> wrote:
> I personally find that putting configuration details into a file is superior
> approach compared to zillion of options or environment variables. Say, if you
> build a project with automake with zillion of configure options, those options
> are put directly in Makefile, in your build dir, so if you remove your build tree,
> you have to re-figure those options next time you build.
>
> In fact, this is a flaw shared by CMake -- if you configure some project as:
>
>   cmake -Dfoo=blah -DBOOST_ROOT=whatever ../src
>
> it helpfully puts those options into the cache file. Unfortunately, when the
> configure magic confuses itself (which does happen), your only solution is to
> remove the cache, and then you need to recall and pass the same options again.

FWIW, CMake has an option to provide an initial cache file (using -C
cache-filename). So, you can place those configuration details into
your own initial cache file, and ask CMake to start with that
configuration (configuring whatever else it needs) if you need to
re-configure your tree.

- Doug

Vladimir Prus

unread,
Jul 29, 2009, 1:00:46 PM7/29/09
to bo...@lists.boost.org
Doug Gregor wrote:

> On Wed, Jul 29, 2009 at 5:14 AM, Vladimir Prus<vlad...@codesourcery.com> wrote:
>> I personally find that putting configuration details into a file is superior
>> approach compared to zillion of options or environment variables. Say, if you
>> build a project with automake with zillion of configure options, those options
>> are put directly in Makefile, in your build dir, so if you remove your build tree,
>> you have to re-figure those options next time you build.
>>
>> In fact, this is a flaw shared by CMake -- if you configure some project as:
>>
>> cmake -Dfoo=blah -DBOOST_ROOT=whatever ../src
>>
>> it helpfully puts those options into the cache file. Unfortunately, when the
>> configure magic confuses itself (which does happen), your only solution is to
>> remove the cache, and then you need to recall and pass the same options again.
>
> FWIW, CMake has an option to provide an initial cache file (using -C
> cache-filename). So, you can place those configuration details into
> your own initial cache file, and ask CMake to start with that
> configuration (configuring whatever else it needs) if you need to
> re-configure your tree.

Does initial cache use the same syntax as the ordinary cache, and can be edited
using the GUI?

- Volodya

John Maddock

unread,
Jul 29, 2009, 1:23:07 PM7/29/09
to bo...@lists.boost.org
>I looked through the old solution and it looks like it is just these two:
>icui18n.lib
>icui18nd.lib

I've updated the Jamfile in Trunk, let me know if you spot any other issues,

Doug Gregor

unread,
Jul 29, 2009, 2:21:00 PM7/29/09
to bo...@lists.boost.org
On Wed, Jul 29, 2009 at 10:00 AM, Vladimir

Prus<vlad...@codesourcery.com> wrote:
> Doug Gregor wrote:
>
>> On Wed, Jul 29, 2009 at 5:14 AM, Vladimir Prus<vlad...@codesourcery.com> wrote:
>>> I personally find that putting configuration details into a file is superior
>>> approach compared to zillion of options or environment variables. Say, if you
>>> build a project with automake with zillion of configure options, those options
>>> are put directly in Makefile, in your build dir, so if you remove your build tree,
>>> you have to re-figure those options next time you build.
>>>
>>> In fact, this is a flaw shared by CMake -- if you configure some project as:
>>>
>>> cmake -Dfoo=blah -DBOOST_ROOT=whatever ../src
>>>
>>> it helpfully puts those options into the cache file. Unfortunately, when the
>>> configure magic confuses itself (which does happen), your only solution is to
>>> remove the cache, and then you need to recall and pass the same options again.
>>
>> FWIW, CMake has an option to provide an initial cache file (using -C
>> cache-filename). So, you can place those configuration details into
>> your own initial cache file, and ask CMake to start with that
>> configuration (configuring whatever else it needs) if you need to
>> re-configure your tree.
>
> Does initial cache use the same syntax as the ordinary cache,

Yes.

> and can be edited
> using the GUI?

No, but that would be a big improvement.

- Doug

Vladimir Prus

unread,
Jul 29, 2009, 2:51:47 PM7/29/09
to bo...@lists.boost.org
Doug Gregor wrote:

> On Wed, Jul 29, 2009 at 10:00 AM, Vladimir
> Prus<vlad...@codesourcery.com> wrote:
>> Doug Gregor wrote:
>>
>>> On Wed, Jul 29, 2009 at 5:14 AM, Vladimir Prus<vlad...@codesourcery.com> wrote:
>>>> I personally find that putting configuration details into a file is superior
>>>> approach compared to zillion of options or environment variables. Say, if you
>>>> build a project with automake with zillion of configure options, those options
>>>> are put directly in Makefile, in your build dir, so if you remove your build tree,
>>>> you have to re-figure those options next time you build.
>>>>
>>>> In fact, this is a flaw shared by CMake -- if you configure some project as:
>>>>
>>>> cmake -Dfoo=blah -DBOOST_ROOT=whatever ../src
>>>>
>>>> it helpfully puts those options into the cache file. Unfortunately, when the
>>>> configure magic confuses itself (which does happen), your only solution is to
>>>> remove the cache, and then you need to recall and pass the same options again.
>>>
>>> FWIW, CMake has an option to provide an initial cache file (using -C
>>> cache-filename). So, you can place those configuration details into
>>> your own initial cache file, and ask CMake to start with that
>>> configuration (configuring whatever else it needs) if you need to
>>> re-configure your tree.
>>
>> Does initial cache use the same syntax as the ordinary cache,
>
> Yes.

Hmm, does not work for me:

$ cp CMakeCache.txt initial
$ cmake -C initial .
loading initial cache file initial
CMake Error: Error in cmake code at
/tmp/x/initial:17:
Parse error. Expected a command name, got unquoted argument with text "//Path".
CMake Error: Error processing file:initial
-- Configuring incomplete, errors occurred!
$ cmake --version
cmake version 2.6-patch 2

Am I doing something wrong?

>> and can be edited
>> using the GUI?
>
> No, but that would be a big improvement.

OK. Regardless of the reason for the above error -- which might well be my error --
I think I now understand the attractive parts of CMake configuration framework, and
will make use of that understanding.

Thanks,
Volodya

KSpam

unread,
Jul 29, 2009, 3:22:08 PM7/29/09
to bo...@lists.boost.org
> >>> FWIW, CMake has an option to provide an initial cache file (using -C
> >>> cache-filename). So, you can place those configuration details into
> >>> your own initial cache file, and ask CMake to start with that
> >>> configuration (configuring whatever else it needs) if you need to
> >>> re-configure your tree.
> >>
> >> Does initial cache use the same syntax as the ordinary cache,
> >
> > Yes.
>
> Hmm, does not work for me:
>
> $ cp CMakeCache.txt initial
> $ cmake -C initial .
> loading initial cache file initial
> CMake Error: Error in cmake code at
> /tmp/x/initial:17:
> Parse error. Expected a command name, got unquoted argument with
> text "//Path". CMake Error: Error processing file:initial
> -- Configuring incomplete, errors occurred!
> $ cmake --version
> cmake version 2.6-patch 2
>
> Am I doing something wrong?

The cmake file(s) that can be passed in via the "-C" option do not have the
same syntax as CMakeCache.txt. Instead they have the normal CMake syntax
(which I find easier to work with). For instance, you could have a file
initial.cmake:

# Contents of initial.cmake
set(CMAKE_INSTALL_PREFIX "my/path/for/install" CACHE STRING "Where to put
installed files" FORCE)

This file could then be used:

cmake -C initial.cmake my/path/to/source/tree

> OK. Regardless of the reason for the above error -- which might well be my
> error -- I think I now understand the attractive parts of CMake
> configuration framework, and will make use of that understanding.

I would like to add that although the GUI and the easy to modify configuration
of CMake is very nice, it is a very small fraction of the CMake configuration
framework. Perhaps the more important feature is the ability to find third-
party libraries on any number of host system configurations "automagically".
I would expect that this feature is also one of the more difficult to
duplicate.

Respectfully,
Justin

Doug Gregor

unread,
Jul 29, 2009, 3:58:34 PM7/29/09
to bo...@lists.boost.org
On Wed, Jul 29, 2009 at 11:21 AM, Doug Gregor<doug....@gmail.com> wrote:
> On Wed, Jul 29, 2009 at 10:00 AM, Vladimir
> Prus<vlad...@codesourcery.com> wrote:
>> Doug Gregor wrote:
>>> FWIW, CMake has an option to provide an initial cache file (using -C
>>> cache-filename). So, you can place those configuration details into
>>> your own initial cache file, and ask CMake to start with that
>>> configuration (configuring whatever else it needs) if you need to
>>> re-configure your tree.
>>
>> Does initial cache use the same syntax as the ordinary cache,
>
> Yes.

Err, I was wrong; thanks to Justin for correcting my moronicity.

KTC

unread,
Jul 29, 2009, 5:06:40 PM7/29/09
to bo...@lists.boost.org
John Maddock wrote:
>>> Sorry I must have missed that, what's the problem/fix?
>>
>> The "error: link=shared together with runtime-link=static is not
>> allowed" problem is the newest problem I have, appeared in recent
>> versions, prevents us from doing a complete build.
>
> You simply can not mix dll's with the static runtime - doing so will in
> almost all circumstances cause your application to crash.

My complaint here wasn't that this was fixed, but rather that I think
someone should be able to do a --build-type=complete and have all the
supported variant of the libraries built. In the case of with ICU it
would only build the shared versions. It shouldn't still try to build
both when building with ICU thus causing the error and not building
anything at all.

> Well... As of ICU-4.2, the names of the libraries are documented here:
> http://userguide.icu-project.org/icufaq#TOC-How-do-I-install-the-binary-version
> and match what the Jamfile assumes (and what I downloaded in the binary
> package), this information:
> http://source.icu-project.org/repos/icu/icu/tags/release-4-2-1/readme.html#HowToPackage
> also uses the same filenames, for example icuin.lib/dll and not
> icui18n.lib/dll.

Um, the problem isn't that the build system wanted icuin and got given
icui18n etc, it's the other way round. It wants icu18n & icudata, and is
given icuin & icudt instead.
if $(HAVE_ICU)
{
gHAS_ICU = true ;
gICU_CORE_LIB = icuuc ;
gICU_IN_LIB = icui18n ;
gICU_DATA_LIB = icudata ;
gICU_CONFIG_CHECKED = true ;
}

The else if clause right below that is kinda complicated and I'm not
entirely following it, but it seems the build system is following two
different path both building with ICU when ICU_PATH is set depending on
whether HAVE_ICU is set. (My reading of the documentation suggest
setting -sHAVE_ICU=1 to build with ICU.)

As a test, I just downloaded the latest ICU 4.2 binary on Windows with
VC9 and attempting to build using trunk, setting -sHAVE_ICU=1
-sICU_PATH="...".
...failed updating 5 targets...
...skipped 6 targets...
...updated 47 targets...
When only ICU_PATH is set, it builds fine.
...updated 58 targets...

KTC

--
Only two things are infinite,
the Universe and Stupidity.
And I'm not quite sure about the former.
- Albert Einstein

KTC

unread,
Jul 29, 2009, 5:21:37 PM7/29/09
to bo...@lists.boost.org
Vladimir Prus wrote:
> KTC wrote:
>
>>
>> Nope, MPI requires modification of user-config.jam or building it on its
>> own with --with-mpi. Why? No other optional components build that way.
>> So they look to see how they do that, and does it.
>
> Do you actually want Boost.MPI? I kinda expect anybody who wants to use
> Boost.MPI to already have MPI installed.

Personally, probably not. But my issue with it was that MPI's build
behaviour differ from all the other libraries. It's a minor thing anyway
because it's well documented both in the docs, and in the text return
from the build screen when building without specifying --without-mpi.

> Did you file any issues at svn.boost.org? This is the first time I hear about
> any expat-related problems whatsoever.

Not yet. Trac kinda confuses me. :D I never encountered the expat issue
before either because I've only just upgraded to 1.39, and it's the
first time I tried building with expat. I'll file something though.

Steven Watanabe

unread,
Jul 29, 2009, 5:39:25 PM7/29/09
to bo...@lists.boost.org
AMDG

KTC wrote:
> John Maddock wrote:
>>>> Sorry I must have missed that, what's the problem/fix?
>>>
>>> The "error: link=shared together with runtime-link=static is not
>>> allowed" problem is the newest problem I have, appeared in recent
>>> versions, prevents us from doing a complete build.
>>
>> You simply can not mix dll's with the static runtime - doing so will
>> in almost all circumstances cause your application to crash.
>
> My complaint here wasn't that this was fixed, but rather that I think
> someone should be able to do a --build-type=complete and have all the
> supported variant of the libraries built. In the case of with ICU it
> would only build the shared versions. It shouldn't still try to build
> both when building with ICU thus causing the error and not building
> anything at all.

I agree. The old behavior was to disable targets that used this bad
combination instead of issuing an error. The error message is mostly
useful, but causes problems in this particular case.

In Christ,
Steven Watanabe

OvermindDL1

unread,
Jul 29, 2009, 9:28:11 PM7/29/09
to bo...@lists.boost.org

Ah, in that case my very old solution I looked at had the correct
names (maybe I changed them in the solution instead of just renaming
the files), and the new solution still uses the new naming convention,
hence Boost needs to be updated.

John Maddock

unread,
Jul 30, 2009, 4:45:47 AM7/30/09
to bo...@lists.boost.org

OK I'll look into that some more: however the intension was that HAVE_ICU
and ICU_PATH should not be mixed, HAVE_ICU is designed for Unix like systems
that have the icu binaries installed in the usual std locations under the
std Unix naming convention for ICU. I'll try and tweak the logic so that
ICU_PATH takes precedence in that case.

Thanks, John.

Boris Schaeling

unread,
Jul 30, 2009, 5:20:42 AM7/30/09
to bo...@lists.boost.org
On Tue, 28 Jul 2009 13:00:11 +0200, Vladimir Prus
<vlad...@codesourcery.com> wrote:

> [...]
>> I have another question: What exactly does <find-shared-library> do?
>> Does
>> it automatically define and use a lib target like:
>>
>> lib xy : : <name>xy <link>shared ;
>
> It's the other way around, actually. <find-shared-library> instructs to
> link
> against named library, so
>
> <find-shared-library>x
>
> results in
>
> -lx
>
> on linux (and x.lib on windows). 'shared' means to make sure it's
> actually
> shared.

If I need to set a path to x on a platform because I know
<find-shared-library> won't be able to find x automatically can I add a
"lib x" rule to a configuration file as a fallback mechanism? Then I could
use <search> to help <find-shared-library> to find x?

Boris

Vladimir Prus

unread,
Jul 30, 2009, 5:57:12 AM7/30/09
to bo...@lists.boost.org
Boris Schaeling wrote:

> On Tue, 28 Jul 2009 13:00:11 +0200, Vladimir Prus
> <vlad...@codesourcery.com> wrote:
>
>> [...]
>>> I have another question: What exactly does <find-shared-library> do?
>>> Does
>>> it automatically define and use a lib target like:
>>>
>>> lib xy : : <name>xy <link>shared ;
>>
>> It's the other way around, actually. <find-shared-library> instructs to
>> link
>> against named library, so
>>
>> <find-shared-library>x
>>
>> results in
>>
>> -lx
>>
>> on linux (and x.lib on windows). 'shared' means to make sure it's
>> actually
>> shared.
>
> If I need to set a path to x on a platform because I know
> <find-shared-library> won't be able to find x automatically can I add a
> "lib x" rule to a configuration file as a fallback mechanism? Then I could
> use <search> to help <find-shared-library> to find x?

You can, but it's somewhat non-direct. The <library-path> is the low-level
feature. That is, if you define

lib xy : : <name>xy <link>shared <search>foo ;

the targets that use xy will get additional

<find-shared-library>xy <library-path>foo

properties. There are little reasons to directly use the latter features
these days, to be honest.

- Volodya

Boris Schaeling

unread,
Jul 30, 2009, 6:06:21 AM7/30/09
to bo...@lists.boost.org
On Thu, 30 Jul 2009 11:57:12 +0200, Vladimir Prus
<vlad...@codesourcery.com> wrote:

> [...]You can, but it's somewhat non-direct. The <library-path> is the

> low-level
> feature. That is, if you define
>
> lib xy : : <name>xy <link>shared <search>foo ;
>
> the targets that use xy will get additional
>
> <find-shared-library>xy <library-path>foo
>
> properties. There are little reasons to directly use the latter features
> these days, to be honest.

Ah, so you recommend to always use the lib rule? Then I won't add
<find-shared-library> and <library-path> to my tutorial - if there are too
many details and too many options people just get lost and probably give
up trying to find out what to use when.

Boris

Vladimir Prus

unread,
Jul 30, 2009, 6:44:56 AM7/30/09
to bo...@lists.boost.org
Boris Schaeling wrote:

> On Thu, 30 Jul 2009 11:57:12 +0200, Vladimir Prus
> <vlad...@codesourcery.com> wrote:
>
>> [...]You can, but it's somewhat non-direct. The <library-path> is the
>> low-level
>> feature. That is, if you define
>>
>> lib xy : : <name>xy <link>shared <search>foo ;
>>
>> the targets that use xy will get additional
>>
>> <find-shared-library>xy <library-path>foo
>>
>> properties. There are little reasons to directly use the latter features
>> these days, to be honest.
>
> Ah, so you recommend to always use the lib rule? Then I won't add
> <find-shared-library> and <library-path> to my tutorial - if there are too
> many details and too many options people just get lost and probably give
> up trying to find out what to use when.

Yes, I think that right :-) *Users* should not have to use those features.

- Volodya

Gennadiy Rozental

unread,
Aug 1, 2009, 12:53:47 PM8/1/09
to bo...@lists.boost.org
Dmitry Goncharov wrote:
> There is a restriction that shared and static versions of
> libunit_test_framework are not interchangeable.
> This makes it difficult to ship unit tests since the author of a unit
> test cannot predict what type of libunit_test_framework (shared or
> static) the user has on their machine.

1. This subject is discussed in length. Boost.Test opted for portability
in between platform, instead of interchangeability between static and
shared libraries. This is not a restriction, this is feature ;)

2. Am I to understand that you are library developer who ships unit
tests along with library?

3. If answer is yes, do you ship your own makefiles? if yes, you can
enforce specific library there.

4. If not, you can use single header variant of UTF and do not depend on
library at all. It's not like your users are going to build your test
modules over and over.

5. Your last option if none of the above fits is to make notes in
documentation ;)

Gennadiy

Dmitry Goncharov

unread,
Aug 3, 2009, 5:36:35 AM8/3/09
to bo...@lists.boost.org

Thanks for your reply,

Gennadiy Rozental wrote:

> 1. This subject is discussed in length. Boost.Test opted for
> portability in between platform, instead of interchangeability between
> static and shared libraries. This is not a restriction, this is
> feature ;)

Can't really see how interchangeability between static and shared
libraries prevents portability between platforms.
Anyway, from your answer i understand that it is going to stay this way.


>
> 2. Am I to understand that you are library developer who ships unit
> tests along with library?

That's right.


>
>
> 3. If answer is yes, do you ship your own makefiles?

yes


> if yes, you can enforce specific library there.

It is possible to enforce a specific library. It's also uncomfortable
for the user.


>
> 4. If not, you can use single header variant of UTF and do not depend
> on library at all.

That's right. This will increase compilation time.

> It's not like your users are going to build your test modules over and
> over.

That's right, the users aren't going to build test modules over an over.
The developer (e.g. me) builds tests modules over and over.


>
> 5. Your last option if none of the above fits is to make notes in
> documentation ;)
>
> Gennadiy
>
>

BR, Dmitry

Gennadiy Rozental

unread,
Aug 3, 2009, 3:36:01 PM8/3/09
to bo...@lists.boost.org
Dmitry Goncharov <dgoncharov <at> unison.com> writes:

>
>
> Thanks for your reply,
>
> Gennadiy Rozental wrote:
>
> > 1. This subject is discussed in length. Boost.Test opted for
> > portability in between platform, instead of interchangeability between
> > static and shared libraries. This is not a restriction, this is
> > feature ;)
> Can't really see how interchangeability between static and shared
> libraries prevents portability between platforms.

The problem is that main function can't reside inside the shared library (at
least not if portability is a concern), but it can inside the static one.
Later was a default which we wanted to continue to employ. To properly support
shared library usage variant I had to go with a bit different support scheme,
with main function outside. Thus we came to the current state of affairs.


> > 3. If answer is yes, do you ship your own makefiles?
> yes
> > if yes, you can enforce specific library there.
> It is possible to enforce a specific library. It's also uncomfortable
> for the user.

How? I believe you only need to add -static in proper place in command line.

> > 4. If not, you can use single header variant of UTF and do not depend
> > on library at all.
> That's right. This will increase compilation time.
>
> > It's not like your users are going to build your test modules over and
> > over.
> That's right, the users aren't going to build test modules over an over.
> The developer (e.g. me) builds tests modules over and over.

It should be trivial to have makefiles/test modules to support both variants, so
that you will use shared library, and your users will use single header variant.

Gennadiy

Dmitry Goncharov

unread,
Aug 8, 2009, 11:35:31 AM8/8/09
to bo...@lists.boost.org

Gennadiy Rozental wrote:
>
> The problem is that main function can't reside inside the shared library (at
> least not if portability is a concern), but it can inside the static one.
> Later was a default which we wanted to continue to employ. To properly support
> shared library usage variant I had to go with a bit different support scheme,
> with main function outside. Thus we came to the current state of affairs.
>
>

It is possible to have function main() in a dedicated library, not in
libboost_unit_test_framework.
In this case users who don't want to implement main() can link against
that dedicated library.
This lets static and dynamic libboost_unit_test_framework libraries be
interchangeable.


BR, Dmitry

Gennadiy Rozental

unread,
Aug 8, 2009, 1:02:07 PM8/8/09
to bo...@lists.boost.org
Dmitry Goncharov <dgoncharov <at> unison.com> writes:

> It is possible to have function main() in a dedicated library, not in
> libboost_unit_test_framework.
> In this case users who don't want to implement main() can link against
> that dedicated library.
> This lets static and dynamic libboost_unit_test_framework libraries be
> interchangeable.

There is also such thing as backward compatibility. Don't you think users who
currently use static library variant of UTF would complain if all their test
would start failing linking?

There is an option already to have static library without main
BOOST_TEST_NO_MAIN, but it had to be used when library is built.

Gennadiy

Dmitry Goncharov

unread,
Aug 8, 2009, 1:17:31 PM8/8/09
to bo...@lists.boost.org

Gennadiy Rozental wrote:
> There is also such thing as backward compatibility. Don't you think users who
> currently use static library variant of UTF would complain if all their test
> would start failing linking?
>

I am not expecting anybody to break backward compatibility now.
This just one solution that could have been implemented and it wasn't
for some reason.
I'm not sure that solution is worthy since it increases complexity.
IMHO, the correct solution is to always have main() in the unit test and
never have it in a library.
I started this thread to find out what caused this uncomfortable
situation about static and dynamic libraries.
From you answers its clear that the situation is this just because it
has been this way from the beginning.

> There is an option already to have static library without main
> BOOST_TEST_NO_MAIN, but it had to be used when library is built.
>
>
>

Thanks for your help.

BR, Dmitry

Gennadiy Rozental

unread,
Aug 9, 2009, 1:16:39 PM8/9/09
to bo...@lists.boost.org
Dmitry Goncharov wrote:
>
>
> Gennadiy Rozental wrote:
>> There is also such thing as backward compatibility. Don't you think
>> users who
>> currently use static library variant of UTF would complain if all
>> their test
>> would start failing linking?
>>
> I am not expecting anybody to break backward compatibility now.
> This just one solution that could have been implemented and it wasn't
> for some reason.

Originally the Boost.Test only supported static library. The main was
included to minimize the effort developer need to apply to write simple
est test module. It's still valid point. Unfortunately though we can't
do it with shared lib. Also some users (like you) prefer to have their
own entry point.

> I'm not sure that solution is worthy since it increases complexity.

It does. And it's not acceptable IMO.

> IMHO, the correct solution is to always have main() in the unit test and
> never have it in a library.

IMO it's not correct to force 95% of the users to write trivial main.

> I started this thread to find out what caused this uncomfortable
> situation about static and dynamic libraries.

IMO it's uncomfortable for small percent of users (in very particular
combination of conditions). And if then, solution always exists.

> From you answers its clear that the situation is this just because it
> has been this way from the beginning.

I guess. And I still believe it's good compromise for most users.

Gennadiy

Reply all
Reply to author
Forward
0 new messages