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

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-07-10 17:16:32

From: <gclbb-jamboost_at_[hidden]>

> >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
> COMO_ROOT_DIRECTORY? And so on.

Are you one of those people who can't take the documentation at face value,
and needs to know exactly how things are accomplished (you /do/ get to look
at the EDG sources, after all)? I'm asking because we put substantial
effort into the docs for this last release, and they seem perfectly clear
to me. Of course, I wrote them, but then I went on to explain them to
you... so is there something wrong with the docs, or are docs just useless
for you in general -- or is it something else?

To answer your question, variables can't set other variables. There's jam
code which in essence, says "if COMO_PATH is set, set COMO_INCLUDE_PATH to
$(COMO_PATH)/libcomo $(COMO_PATH)/libcomo/cnames". If you need to
understand how the Jam code does that, read the Jam docs and do some
experiments.

> >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?

I don't understand what "explicitly" or "as a fallout" means.
If COMO_PATH is unspecified, the tools are invoked without any path
qualification. Is that "as a fallout"?

> >Because como installations are not as uniform as Borland installations.
>
> Hmmm. I wonder is this is a misunderstanding of como, or the
> ramification of something such as an earlier bug it had?

Neither. As stated below, people put the library in all kinds of places
relative to the executable. Just for example. That means there's no single
comeau installation directory structure, in contrast to BCC which gets
installed in one big tree, period.

> >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?),
>
> Right, we don't mandate it, because different groups of people
> want it in different places, and different groups of people want
> different ways of specifying it. (This is similar to the implicit
> boost inclusion addition we have going on in the other NG.)

Right. That's what we're accomodating with these variables.

> But this is what's unclear in the jamfile too though,
> if I'm understanding it right, because it seems to require
> that libcomo will be in the Comeau directory tree.

Only if you want to do it with a single variable setting: COMO_ROOT. That's
why we let people set COMO_STDLIB_PATH separately.

> >so people need to be ablet to adjust their variables to cope.
> As one possibility, yes.

Are there other possibilities?

> >> 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.
>
> Oops, right I agree with that. I had meant as with BCCROOT.
> For instance, it there's a BCCROOT, why isn't there a COMOROOT,
> and so on?

Mostly historical reasons. Jam automatically splits the values variables
with names not ending in "PATH" at whitespace boundaries. When we
discovered that people were having problems with spaces in pathnames being
broken up, there was a period when we were being very careful to be write
new toolsets with config variables named xxxPATH. Eventually we discovered
how to reconstitute the spaces so that it would be a non-issue.

> >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
>
> Ok, I think I understand this sentiment, and have the same kind of
> considerations myself in my own work. And it's one of the reasons
> why we're removed environment variable depencies for Comeau C++
> in some setups.
>
> >(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).

If you're not certain, how could anyone else be?

> >and many of them use "INCLUDE").
>
> Right. And also things such as link.exe :)

Huh? Oh, yeah, comeau requires that the backend linker be in the PATH
doesn't it?

> >If you want to invoke a
> >multi-compiler build under these circumstances, you're just
> >asking for trouble.
>
> Agree, probably wholeheartedly, on this generally, it's some of
> the particulars that I'm not yet getting.

Ask some very particular questions, and I'll try to help.

> >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.
>
> If for instance, somebody want to use STLPort with say BCC 5.x,
> or let's say that a standard library vendors add support for
> more compilers, would it mean that say the borland-tools jam
> file would look more like the como-tools jam file?

I'm not sure what you're driving at here.

I /can/ say that in Boost Build v1, standard library support is generally
tied rather tightly to the toolset (and somewhat of a mishmosh --
msvc-stlport has much better stlport support than gcc-stlport, for
example). In Boost Build v2, they will be much more independent.

However, if you look at any of the xxx-stlport toolsets you can see that
they're based upon the non-stlport toolsets, so you don't have to build
standard library support directly into the base toolset.

> >> >> 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.
>
> Let me rephrase to see if I understand:
> * Because como is more flexible/less restrictive that other compiler
> interfaces.
> * Because compilers often clash with each other

That only answers the "why" part, but the questions are yours, so if you're
satisfied, I am too.
BTW, I don't agree with the premise of your first "Because...", generally
speaking.

I guess I should clarify that although Jam variables may come from the
environment, they aren't automatically transmitted to the environment of
its build actions. So whether Comeau C++ uses a variable setting or not is
irrelevant from the POV of Jam variable settings. When you set these
variables, you're just telling Jam how to conjure up the right
command-lines with which to invoke como.

HTH,
Dave