Question

What’s the best practice for including Boost libraries in the built process?

To illustrate, assume that our project makes use of Boost’s regular expressions and is compiled as follows:

g++ -lboost_regex -o main main.cpp

… which means that I could write a Makefile which contains just the following:

LDFLAGS+=-lboost_regex

Unfortunately, this doesn’t work on my system:

$ make main
ld: library not found for -lboost_regex
collect2: error: ld returned 1 exit status

Which is understandable since I didn’t specify a library path, and Boost is installed in a location where the compiler doesn’t find it.

I don’t want to hard-code that path in my Makefile, obviously. Otherwise, the project cannot be built on other machines.

One solution would be to set LD_LIBRARY_PATH but this is discouraged.

The “real” solution for normal libraries is to use pkg-config, e.g. like this:

LDFLAGS+=$(shell pkg-config --libs sqlite3)

… which is resolved to something along the lines of -L/path/to/sqlite/lib -lsqlite3.

Unfortunately, Boost still doesn’t support pkg-config.

This leaves me in a dilemma. There doesn’t seem to be a universal way of determining the Boost library installation path. How do other projects handle this?

(Someone suggested the environment variable BOOST_ROOT but that doesn’t seem to be universally present either, you’d need to manually set it in on one of the bashrc/profile files.)

Answer 1

Since I’m the one who suggested using BOOST_ROOT, I may aswell put it up as an answer.

Background: Boost’s bjam build program requires a BOOST_ROOT environment variable if it’s not executed inside the boosts installation root.
With this thought, one might aswell “rely” on it, i.e. require it to be present when make is invoked by either having it as a full environment variable all the time or just have it set during the session / command like BOOST_ROOT=/foo/bar/boost make.