Re: [jamboost] Re: Re: Re: [boost] Comeau setup

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-07-07 13:04:29

----- Original Message -----
From: <gclbb-jamboost_at_[hidden]>
followd by a question-mark ;-)
> >Does http://www.boost.org/tools/build/como-tools.html fail to explain
it?
> >If so, please ask a specific question.
>
> I'm still confused over como-tools.html, so I'll ask my question
> statement as a question :} :
> What is
> the difference between COMO_PATH, COMO_BIN_PATH, COMO_BIN_DIRECTORY,
> COMO_BASE_SETUP, and COMO_PATH_SETUP and how do they [need to] interact
> and/or how are they [necessary to be] different from just
> PATH and COMO_PATH? :)

I don't understand this question - it's too general.
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.

The system will only resort to using PATH for the como toolset if you don't
specify COMO_PATH.

> Seriously. I see for instance that
> borland-tools.html only discusses BCCROOT. Why doesn't como
> need just COMOROOT then?

Because como installations are not as uniform as Borland installations. For
example, you tell people to install separate headers and a separate
libcomo. Your instructions are not very clear about where things should go
(do you even mandate it?), so people need to be ablet to adjust their
variables to cope.

> And/or why isn't there just a ROOT
> or COMPILER_ROOT for all compilers?

Because I don't want to make people re-install all their tools under a
common directory just to make Boost.Build happy.

> Or why isn't it just assumed to be in PATH?

Because people like me with 11 working toolsets on their systems might not
want to try to get the environment variables/PATH which the tools directly
depend on configured so they all work at the same time, without conflicts.
Compiler tools tend to use very general short names for environment
variables which they depend on in order to work right (e.g. como uses
"LIB", and many of them use "INCLUDE"). If you want to invoke a
multi-compiler build under these circumstances, you're just asking for
trouble.

Of course, if you set the Boost.Build toolset variables in your environment
before invoking bjam, it begs the same questions -- this is part of the
reason we're moving away from global variables for Boost.Build v2 -- but at
least we are using longer qualified names like COMO_xxxx instead of just
xxxx in v1.

> >> And also what program uses these "new" variables, and why?
> >
> >bjam uses them when using the como toolset in order to know what it
needs
> >to stick in the command-line.
> >
> >What's "new" about them?
>
> I probably should have said "extra". Extra in the sense that
> Comeau C++ normally doesn't use them, so what does use then,
> where does it use them, and why?

I hope I've already answered that at this point. If you still have
questions, please ask.

-Dave