Re: [boost] Bug#429533: new proposal: boost-config

From: Domenico Andreoli (cavokz_at_[hidden])
Date: 2007-08-04 22:39:49

On Sat, Aug 04, 2007 at 07:55:26AM +0200, Martin Wille wrote:
> Vladimir Prus wrote:
> > Martin Wille wrote:
> > 
> >> Vladimir Prus wrote:
> >>
> >>
> >>> What is going to happen? It sounds like you've omitted some part of
> >>> your email.
> >>
> >> The message looks complete here.
> > 
> > Let me clarify -- the message goes like this:
> > 
> >> Now Joe User writes his app on the Fedora system and links Boost.DateTime
> >> using the familiar -lboost_date_time switch. He builds the app and
> >> tries it on both his Fedora system and the friend's Debian one.  What is
> >> going to happen?
> >>
> >> BTW, ....
> > 
> > So either "What is going to happen?" is a question to recipients of the
> > email (and I don't know what exactly is being asked), or Domenico meant
> > do tell what is going to happen, but did not.
> 
> 
> Oh, I see. I considered it a rethoric question: the application won't
> work without recompiling because the (dynamically linked) Boost
> libraries won't be found.
> 
> Of course, it wouldn't work even if those libraries were found on the
> other system, because the libraries are not binary compatible.
> 
> 
> There are at least two solutions for the OP:
> 
> 1. embed Boost into your software. This seems to be a common practice.
> Not desirable on embedded systems.

I don't think people is very eager to build Boost from scratch. IMHO this
is a common practice because is still more difficult to manage correct
Boost installations respect to other libraries. Boost was clearly not
thought to be packaged and installed to make 3rd party use it.

I also tried to use Boost.Build to build my software in the hope it
would have correctly managed decorations but it does not work this way
out of the Boost source tree.

> 2. write a script that configures your software for the target system.
> This isn't an extremely difficult, even without a boost-config script,
> except, maybe, for finding the versions of libraries used by Boost
> (Python, ICU, etc).

Free software world had this kind of problems and some "standard"
solutions have been developed right to stop people reinventing the wheel.

Moreover, it frequently happens that some library build flags have to
be used also at application build time, so the library user need to
have a way to figure them out.

-----[ Domenico Andreoli, aka cavok
 --[ http://www.dandreoli.com/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50