Library dependencies

| Home | Libraries | People | FAQ | More

## Library dependencies

The previous example was simple. Often, there are long chains of dependencies between libraries. The main application is a thin wrapper on top of library with core logic, which uses library of utility functions, which uses boost filesystem library. Expressing these dependencies is straightforward:

    lib utils : utils.cpp /boost/filesystem//fs ;
    lib core : core.cpp utils ;
    exe app : app.cpp core ;

So, what's the reason to even mention this case? First, because it's a bit more complex that it seems. When using shared linking, libraries are build just as written, and everything will work. However, what happens with static linking? It's not possible to include another library in static library. Boost.Build solves this problem by returning back library targets which appear as sources for static libraries. In this case, if everything is built statically, the "app" target will link not only "core" library, but also "utils" and "/boost/filesystem//fs".

So, the net result is that the above code will work for both static linking and for shared linking.

Sometimes, you want all applications in some project to link to a certain library. Putting the library in sources of all targets is possible, but verbose. You can do better by using the <source> property. For example, if "/boost/filesystem//fs" should be linked to all applications in your project, you can add <source>/boost/filesystem//fs to requirements of the project, like this:

    project
       : requirements <source>/boost/filesystem//fs
       ;