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

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:

-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.

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.

Chris