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