Boost logo

Boost-Build :

From: David Abrahams (gclbb-jamboost_at_[hidden])
Date: 2003-05-14 06:10:47

Vladimir Prus <ghost_at_[hidden]> writes:

> "benign-looking error message"?! That error message means that two virtual
> targets with *different* properties are assigned the same actual Jam target.
> That's very serious bug. And BTW, the failing "direct_request_test" is
> precisely the test which should fail.

OK, OK; I should've known better... <wink>

> Another observation. If you do the change above and run the test, it passed.
> But... here's the output:
> gcc.compile bin/gcc/debug/a.o
> gcc.compile bin/gcc/debug/b.o
> gcc.compile bin/gcc/debug/b.o
> bin/gcc/debug/
> bin/gcc/debug/
> bin/gcc/debug/a
> This duplication compilation can't be right.
>> This property-adjuster idea seems to add a lot of complexity to the
>> system for very little benefit, AFAWCT. Are we missing something?
> I know it's complex, but it's not possible to simply drop it. Let me explain:
> exe a : a.cpp b ;
> lib b : b.cpp ;
> and build request is "bjam define=MACRO". When "b" is requested by "a", the
> build request does not include "MACRO", because <define> is not propagated.
> But it would seem strange that "b" is not compiled with "define=MACRO". The
> property adjuster is the entity that adds free properties from direct build
> request when targets are requested from other main targets, like "b".
> I think we've discussed this in future and agreed that as long as "b" is
> directly requested, "define=MACRO" should be in build properties.
> The rule implemented in property adjuster is
> if main target is requested from another main target and base properties are
> subset of base properties of some directy requested property set, then free
> properties from that properties set are added. I.e. if build request is
> debug define=MACROS
> then "b" will be compiled with the macros only if it's compiled in debug
> variant. For example
> exe a : a.cpp b/<variant>release ;
> lib b : b.cpp ;
> will cause a release version of 'b' to be compiled and linked into 'a'. The
> release version will be compiled without "define=MACROS".

I understand that now. I still think it's an overly-complicated and
general way to get there. I'll need to look a little more-carefully,
but my sense is that something far simpler is possible.

In the meantime, could you:

a. Explain why this code manipulates incidental features in some
places but only free features in others?

b. Add the above (after "let me explain") as a comment to the


Dave Abrahams
Boost Consulting

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at