From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-05-13 01:22:18
David Abrahams wrote:
> Today Ali and I were trying to figure out what this thing is good for.
> Its functionality looked so obscure to us that eventually we decided
> to modify directly-requested-properties-adjuster.adjust so that it
> just returns its argument unmodified, re-run all the tests, and see
> what broke. Well, guess what? If we were willing to comment out a
> benign-looking error message in virtual-target.register-actual-name,
> all the tests passed. It doesn't look like this property adjustment
> is doing anything useful.
"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.
Another observation. If you do the change above and run the test, it passed.
But... here's the output:
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
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".
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