Boost C++ Libraries of the most highly regarded and expertly designed C++ library projects in the world. Herb Sutter and Andrei Alexandrescu, C++ Coding Standards

This is the documentation for an old version of boost. Click here for the latest Boost documentation.

Chapter 27. Frequently Asked Questions

Table of Contents

I'm getting "Duplicate name of actual target" error. What does it mean?
Accessing environment variables
How to control properties order?
How to control the library order on Unix?
Can I get output of external program as a variable in a Jamfile?
How to get the project-root location?
How to change compilation flags for one file?
Why are the dll-path and hardcode-dll-paths properties useful?
Targets in site-config.jam

I'm getting "Duplicate name of actual target" error. What does it mean?

The most likely case is that you're trying to compile the same file twice, with almost the same, but differing properties. For example:

exe a : a.cpp : <include>/usr/local/include ;
exe b : a.cpp ;

The above snippet requires two different compilations of 'a.cpp', which differ only in 'include' property. Since the 'include' property is free, Boost.Build can't generate two objects files into different directories. On the other hand, it's dangerous to compile the file only once -- maybe you really want to compile with different includes.

To solve this issue, you need to decide if file should be compiled once or twice.

  1. Two compile file only once, make sure that properties are the same:

    exe a : a.cpp : <include>/usr/local/include ;
    exe b : a.cpp : <include>/usr/local/include ;
  2. If changing the properties is not desirable, for example if 'a' and 'b' target have other sources which need specific properties, separate 'a.cpp' into it's own target:

    obj a_obj : a.cpp : <include>/usr/local/include ;
    exe a : a_obj ;
  3. To compile file twice, you can make the object file local to the main target:

          exe a : [ obj a_obj : a.cpp ] : <include>/usr/local/include ;
          exe b : [ obj a_obj : a.cpp ] ;

A good question is why Boost.Build can't use some of the above approaches automatically. The problem is that such magic would require additional implementation complexities and would only help in half of the cases, while in other half we'd be silently doing the wrong thing. It's simpler and safe to ask user to clarify his intention in such cases.