Subject: Re: [boost] [Modularization] A new approach to header modularization
From: Christopher Jefferson (chris_at_[hidden])
Date: 2009-06-03 09:00:43
On 29 May 2009, at 08:28, joaquin_at_[hidden] wrote:
> These are points for a lib developer to evaluate, not the Boost
> user. Remember we were
> talking of reasons why users prefer header-only.
> Again, I've listed here my personal reasons (as a user). I think it
> could be instructive to
> try to gather more insight as to why our users prefer header-only
> libs, putting aside
> our own arguments as Boost authors.
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:
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
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.
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk