Boost logo

Boost-Build :

From: David Abrahams (dave_at_[hidden])
Date: 2002-12-23 10:51:04

Vladimir Prus <ghost_at_[hidden]> writes:

> David Abrahams wrote:
>> So ask us some questions; we should try to clear that up.
>>>>>The gcc.jam for V2 really has no rules, only actions and flags
>>>>>settings. Is it possible to inherit actions?
>>>>We can certainly make it possible. There's no a priori reason that
>>>>every toolset needs to have its own "link" action.
>>>Agh.. if "IMPORT" imports actions too (which is the same, IIRC),
>> The same as what?
> "which is the case" was intended. Sorry for such an unintelligible typo.

We had a bug with actions not being associated with module scope,
didn't we? Are you saying that's now fixed, or is that a different
issue having to do with access to globals?

>>>Observe that regression testring already requires a separate utility that
>>>generates XML file. I'm suggesting to add more responsibilities to it.
>> Fine with me.
> OK, need to check if this is fine with Beman.

Actually it would need to be a separate tool. The XML stuff just
munges the output of a bjam run AFAIK.

>> "using" still has too much resonance with something completely
>> different in C++.
> I'm pretty sure that resonanse with C++ is why you've picked that name
> initialy ;-) Am I wrong?

I think so.

> OK, the point you made is good. I'm +0 for "configure".

> It's just a first version. Yes, up to 9 version is better.
>> What are the meanings of "name" and "path" above?
> The meaning of name is simple --- the name used to invoke the compiler.
> E.g 3.2 is called g++-3.2 on Debian. Path --- meant as gcc installation root,
> but actually unused now.

OK, thanks.

>> I had always imagined we would probably make separate "using
>> invocations" for each version of of the toolset we want to configure:
>> using gcc : 2.95 ;
>> using gcc : 3.0.4 /usr/local/gcc-3.0.4 ;
> That's ok, as far as I'm concerned. It's even somewhat better:
> we don't have to dance around argument list of unknown size.


>> GCC installations have a lot of variability: executables, libraries,
>> and include files can all be installed in different locations, so
>> eventually we'd want to accomodate that.
> Yes. I guess that named parameters can help with it. E.g.
> using gcc : 3.0.4
> : binary /dir1
> : headers /dir2
> ;

I'd like to see a clearer named parameter interface, perhaps:

using gcc : 3.0.4
: binary=/dir1
: headers=/dir2

>> As a matter of fact, the "correct" way to deal with GCC is to locate
>> the binary and parse the result of "gcc -v" as shown here:
>> (look for the find_compiler_info function)
> I see. Not sure how can we do that. Maybe, via initial configuration step.
> I.e. user will be asked to run "bjam configure" to detect installed toolsets.

I think that's acceptable, though I believe that eventually we'll want
to expose a builtin that can run a shell command from the parsing
phase of bjam and capture its output.

> I believe that default site-config.jam should attempt to autodetect all
> known toolsets. The syntax is not important, for example, something like
> using gcc : autodetect ;
> Such kind of invocation won't give errors if gcc is not found. Of course, explicit
> using gcc : 3.2 /usr/local/gcc-3.2 ;
> should give error if gcc is not found.

OK, I like it.

>>>OK. I'll add this to BB4 issue (which is assigned to you ;-) )
>> Funny, I don't see the information there. Oh, if I click "view as
>> single screen, and wait... for it to refresh, it's at the bottom in
>> the change history.
>> BTW, scarab, when it works, is really S L O W for me.
> For me, it works not so slow (except for the cases when it drags its 200MB
> tail across the swap space). Let's give it some more time.

I'll try to look at BB4 tonight.

David Abrahams
dave_at_[hidden] *
Boost support, enhancements, training, and commercial distribution

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