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

From: gclbb-jamboost_at_[hidden]
Date: 2002-07-10 14:39:42

In article <019401c225e0$bebcee30$6601a8c0_at_[hidden]>,
David Abrahams <jamboost_at_[hidden]> wrote:
>Comeau wrote:
>> 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.

It's at least partly, and no doubt fully, because I'm confused,
since those names are so closely related so it's hard to see why
they are all needed, and where they are used.

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

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

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

Hmmm. I wonder is this is a misunderstanding of como, or the
ramification of something such as an earlier bug it had?

>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.)

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.

>so people need to be ablet to adjust their variables to cope.

As one possibility, yes.

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

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

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).

>and many of them use "INCLUDE").

Right. And also things such as link.exe :)

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

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

>> >> 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
-- 
Greg Comeau 4.3.0 NEWS: New Windows Backends + 'export' IN July!
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?