Boost logo

Boost-Build :

From: gclbb-jamboost_at_[hidden]
Date: 2002-07-10 17:11:23

In article <20020710151726-r01010800-97aeb38f-0860-0108_at_12.100.89.43>,
Rene Rivera <jamboost_at_[hidden]> wrote:
>[2002-07-10] gclbb-jamboost_at_[hidden] wrote:
>>In article <019401c225e0$bebcee30$6601a8c0_at_[hidden]>,
>>David Abrahams <jamboost_at_[hidden]> wrote:
>>>Comeau wrote:
>>>As for how they interact, if you set COMO_PATH, you will
>>>automatically get defaults for the others. If they point to
>>>the right places as described by the "Semantics" column, you're done.
>>This is one root of my question, because I don't see how.
>>For instance, how does COMO_PATH set COMO_BIN_PATH and
>[from como-tools.jam...]
>[sets COMO_BASE if not already set by the user]

Right, understood.

>[sets COMO_BIN_DIRECTORY to either COMO_BIN_PATH, COMO_BASE/bin/, or "",
>that is more precisely to the first that has a value]

I'm unclear how the 3rd case can occur.

>[etc... :-]
>But that doesn't actually answer your question because the Jam code
>currently(1.28.0) doesn't set "COMO_BIN_PATH", it only uses it and
>therefore can only be set by the user.


>And "COMO_ROOT_DIRECTORY" is not used at all.


>For that not setting COMO_PATH makes things not have values or
>have "" as the value, causing the default como behaviour to occur,
>and requires that it be in the PATH.
>Maybe the detail your aren't aware of yet is that in Jam a variable
>can have no-value. And when it doesn't have a value it's expansion
>doesn't generate a value either.


>For example:
>SOME_VAR = ; # no-value
>ANOTHER_VAR = $(SOME_VAR)/some/stuff ; # still no-value

Ok, so then:




set it to "" if COMO_BASE is not set, because then line BB doesn't
do the assignment to COMO_BIN_DIRECTORY?

>>>The system will only resort to using PATH for the como toolset
>>>if you don't specify COMO_PATH.
>>Does it do that explicitly, or only as a fallout of the jam file(??)
>>being unable to do so?
>As a fallout, see above.


>>>(e.g. como uses "LIB",
>>Actually, that's another question I had, because it looks as if
>>you're adding libcomo into LIB, and probably that's not the
>>best setup (actually, I seem to recall that doesn't work all the time).
>Why is it not best?

Because I don't think it's guaranteed to work -- see below.

>And when doesn't it not work?

It usually works when the lib is a C library or a non-template
based class library, but it is requires instantiations it'll
circumvent that process (which may be ok in some cases,
but generally not).

>As it looks to me it
>actually does that on Windows, but in addition also adds it
>to the command line explicitly.

Ah, yes, I forgot I thought I saw that 2 days ago when I looked.
That's why it appears to work. This is probably harmless in
terms of soemthing going work, but as it's extra, probably
best to take out, especially if functionality is ever given
to LIB (and there might be eventually).

Greg Comeau 4.3.0 NEWS: New Windows Backends + 'export' IN July!
Comeau C/C++ ONLINE ==>
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

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