Dear All, I maintain a couple of open-source apps that use Boost, and my users seem to encounter Boost-related compilation problems more often than I'd like. One common problem is that the names of the libraries are different on different systems. On my Debian system I have, for example, /usr/lib/libboost_thread.so which is a symlink to libboost_thread-gcc-mt-1_33_1.so. My makefile used the shorter name, but then I discovered that some other distributions don't have this symlink - and I believe also that someone who has compiled Boost from source will not have it (is that true?). OK, so I can use the longer name, but should I hard-code the compiler, thread model, and version numbers? I've never tried to compile my code with a different compiler; it's never going to run on Windows but someone might try the Sun or Intel compilers one day, and I don't want to stop that; do I just put $(CC) in there? As for the version, well I'm hopeful that it will still work when 1.34 is released so again I'm not enthusiastic about hard-coding 1.33.1. Another problem is that some people will have installed Boost in a different directory like /usr/local or /opt or ~. I'd like to have all this stuff "just work" without users needing to edit Makefiles or similar. There are, of course, several tools that help solve this sort of thing. GNU autotools (automake, autoconf etc.) are the best-known in the Linux world and many people seem to like them, but I find their mountains of automagically generated shell scripts rather scary, and impossible to debug. I'm aware of Boost's own bjam but feel that each library having its own build system is a bit like each library having its own (incompatible) string type. The approach that I prefer is to write a simple Makefile and to use config scripts to find library configurations. Many libraries supply config scripts that can be invoked by make to determine include and library directories and other settings. For example, libpng has libpng-config: $ libpng-config --cflags -I/usr/include/libpng12 $ libpng-config --libs -lpng12 The makefile can then do CFLAGS += `libpng-config --cflags` and so on. An alternative to each library crafting its own script is the pkg-config program. (man pkg-config). I believe that this is quite widely deployed, but I'm not certain about that. In this case, each library only needs to install a ".pc" file somewhere that the pkg-config program can find it. You can then invoke "pkg-config --cflags libname" etc. The .pc file is quite simple, e.g. here is the one for libexif: prefix=/usr exec_prefix=${prefix} libdir=${exec_prefix}/lib includedir=${prefix}/include Name: libexif Description: Library for easy access to EXIF data Requires: Version: 0.6.13 Libs: -L${libdir} -lexif -lm Cflags: -I${includedir}/libexif As you can see it needs to be customised (by adjusting the first line) when the library is installed, though most is boilerplate. So, I think it would be great if Boost could ship a set of .pc files, one per library. Google tells me that this hasn't been done before. Any thoughts? Can you see any issues that would make this difficult? If you feel that this would be a valuable addition to the project, I would be happy to contribute template .pc files to get started with. However, since I have never built Boost from source and know nothing about the build system, I hope that someone else would volunteer to integrate the files into the build system. I look forward to your comments. (Please CC: me in any replies as I am subscribed to the digest.) Regards, Phil.