Boost logo

Boost-Build :

Subject: [Boost-build] Is is possible to compile with cyclic dependencies?
From: Deniz Bahadir (D.Bahadir_at_[hidden])
Date: 2009-11-24 17:05:49


Hi Everyone,

while developing I realized that Boost.Build seems to have problems
with cyclic dependencies.

I have some applications that link to libraries, which themselves link
to other libraries. I want each application to automatically link to
all (indirectly) needed libraries, however, I do not want to write
down every indirectly used library into the creation-rule.
So, for each library, I am only writing down the directly needed/used
libraries into the "usage-requirements" of the lib-rule. Sadly, some
of the libraries indirectly depent on itself, like in the following
example:
  lib LIB_A : a.cpp : : : <library>LIB_B ;
  lib LIB_B : b.cpp : : : <library>LIB_C ;
  lib LIB_C : c.cpp : : : <library>LIB_A ;
Boost.Build does not like this and does not want to compile.

Is there any way to trick Boost.Build into working with cyclic dependencies?
While googling for this problem, I read something about a workaround
with "alias" but it was not said how exactly this can be done.

Some additional questions:

In my special case I put the libraries into the "usage-requirements"
via an indirect conditional requirement like this:
  lib LIB_A : a.cpp : : : <conditional>@NeededDependencies ;
I hope, this does not complicate the problem!?

Because I also want to automatically have some preprocessor-defines
when compiling a library I am also using the use-feature like this:
  lib LIB_A : a.cpp : <use>LIB_B : : <define>USE_LIB_A <library>LIB_B ;
  lib LIB_B : b.cpp : <use>LIB_C : : <define>USE_LIB_B <library>LIB_C ;
  lib LIB_C : c.cpp : <use>LIB_A : : <define>USE_LIB_C <library>LIB_A ;
So, I expect all three makros "USE_LIB_*" to be defined for every
library when compiling. Is this correct (assuming Boost.Build could be
tricked into working with cyclic redundancies)?

Thanks for your help.
DENIZ


Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk