Re: [boost] [Modularization] A new approach to header modularization

Subject: Re: [boost] [Modularization] A new approach to header modularization
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2009-06-03 10:10:46

Christopher Jefferson wrote:

> I have looked through a number of interactions we have had with boost
> on my project's mailing list, to find exactly why we have been having
> problems with boost. I acknolwedge the current e-mail is extremely
> bias to UNIXy systems, I don't know about windows.
> 
> The problems can be broadly split into two categories:
> 
> 1) ./configure doesn't act "like configure" (as it's actually just a
> wrapper over bjam). This seems to have got much better of late, with
> the new ./bootstrap.sh making things much clearer.
> 
> 2) compiling boost with a short command line is hard.
> 
> If I want someone to compile using gmp and libz (for example) I tell
> them to drop "-lgmp -lz" on the end of the g++ command, or I hardwire
> '-lgmp -lz' into a tiny makefile. Assuming these two libraries are
> installed, that will cover 99% of systems I come across in common usage.
> 
> Now lets imagine I want to include functional (a header-only library).
> 
> #include <boost/functional.hpp> // Fails
> #include <boost-1_39/boost/functional.hpp> // Fails with bizarre errors
> 
> So I have to add:
> 
> -I/usr/local/include/boost-1_39
> 
> Which of course won't work if I then go to another computer, where
> boost isn't in /usr/local/include
> 
> The problem is exacerbated by libraries, where I have to type (on my
> computer)
> 
> -L/usr/local/lib/libboost_thread-xgcc40-mt-1_38.a
> 
> This is little no chance of that line being valid on another system,
> and it's hard to describe to people how to generate it.
> 
> In summation, I think the biggest problem I've had with boost is in
> the 'small simple problems' category. Two suggestions:
> 
> 1) I've seen some systems provide a script which can be executed like:
> 
> g++ my_file ` boostdefs --include --library  `
> 
> Which produce the appropriate flags. Exactly how should a system
> should work is of course up for debate.

There were proposals to add pkg-config generation. However, pkg-config is fairly
limited tool -- it does not even allow to return different compiler flags
for static and shared libraries. So, pkg-config is only good if you have selected
a single variant of Boost that you care about. But in that case, you might
as well build with --layout=system and add -lboost_thread -- no decoration at all.

The idea of using a custom 'boostdefs' tool has came up before, but again,
it's not clear how useful it is when you build several variants. Say, if you
use

        boostdefs --include --library thread --release --threading=single

then your project will not build if single-threaded version of Boost is not
installed, and we're back to 'how to make my project to build'. I actually
believe that on Linux, using --layout=system by default is the right approach.
On Windows, there are some reasons to build several variants with fancy naming,
but there, autolink just handles everything.

> 2) Why not provide a 'libboost' which includes all the libraries
> linked together. If they are dynamically linked this shouldn't create
> a large overhead.

This is interesting idea -- and easily implementable on Linux. Anybody wishes
to comment? I am not sure if this is possible/reasonable on Windows.

- Volodya