From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-02-25 04:07:27
> I'm having difficulties with "usage-requirements".
> It seems this feature does not work as I expected it to ;-(((
> Problem-Description: (Example attached.)
> I have an external library libx:
> The src/Jamfile specifies <include>../include for both requirements
> and usage-requirements. So I should be able to include all headers
> from libx by using <libx/header.h>
> My programm is has several components.
> One library should be liba.
> In the top-level-Jamfile of "program" I specify use-project libx.
> I thought that _all_ sublevel Jamfile use now the correct library
> include for libx. Well, waht happens is that bjam sets the
> library-path only for the main-program which explicitly links to it.
And that's right, two. The 'use-project' rule has very simple
purpose: it gives a symbolic id to project at some location, which
allows you to write @/boost/filesystem/fs instead of long path
(which can change any moment, too).
Usage requirements on libx are applied only to main targets which
use it. However, you can cause all main targets to be linked with
libx: just add <library>/some-path/libx to requirements. If you don't
want to link all targets, but want to add includes for all of them,
you can try <dependency>/some-path/libx in requirements. This should
add usage-requirements, and make all main target depend in libx, but
library won't be linked unless explicitly asked.
The only problem is that it does not work :-( Thanks to your
example I've found the problem, and the planned fix goes very
well together with a couple of other changes I'm planning.
I'll let you know when it works.
> Can someone take a look at this ?
> Start by cd bjam/program/main and run bjam --v2.
> Both main.cpp and bjam/program/liba/test_a.cpp try to include
> #include <libx/test_libx.h>
> It works in main but not in liba.
> Is this a bug, feature or am I misinterpreting the docs ?
I think the latter. Could you tell what parts of docs lead you
to the conclusion you have, so that we could clarify them?
> One other problem is caused by the qt toolset. Both libx and program
> try to use the qt-toolset in their project-root.jam. This leads to
> conflicts. You can reproduce this by removing the comment in
> libx/project-root.jam. Then try to build program with program/Jamfile.
> is not urgent, because I don't plan to build any 3rd party
> qt-enhancement libraries any time soon, but could be a showstopper
> for someone else ;-)
I believe it's fixed now. The bug was that you could not initialize
the QT toolset twice. Now it's possible, provided you give the same
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