From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2006-11-17 16:53:39
Vladimir Prus wrote:
> On Thursday 16 November 2006 03:28, Rene Rivera wrote:
>> I just tried, in HEAD:
>> cd boost-root
>> bjam --v2 -n toolset=gcc --with-thread
>> I was expecting it to *only* *build* the thread library. Instead, after
>> complaining that it can't build some targets, it builds and installs the
>> thread library plus all the headers. Neither "stage" nor "install"
>> should be implicit in any form. This is not only different from what
>> BBv1 does, but is also against what an autoconf "make" does which is
>> what we are trying to model as far as build+install goes.
> I think one 'explicit' should help ;-)
Of course :-) But that reminds me...
I've been thinking of how we set the implicit vs. explicit, as compared
to other attributes. Something that Dave drove into me from the design
of BBv1 is that we really want to stick to using declarative
formulations. And the "explicit <target> ;" just doesn't look
declarative to me, since it's detached from the target declaration :-)
So I had an idea last night while working on some non-boost jamfiles and
thinking about the <build>no functionality. Why not merge the
explicit/implicit aspect with the build aspect? They both control the
functionality, just different options for building. We would have:
feature build : implicit explicit no ;
That splits current "<build>yes" into what we actually have of implicit
vs. explicit building. This way we can do the more convenient of setting
"<build>explicit" at the project level, and then be able to select
specific targets to <build>implicit.
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
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