Re: The right configuration mechanism

From: David Abrahams (dave_at_[hidden])
Date: 2005-08-12 10:19:09

Vladimir Prus <ghost_at_[hidden]> writes:

> On Friday 05 August 2005 19:30, David Abrahams wrote:
>
>> > 2. "path" and "root" specifies directory of the compiler binary, or the
>> > entire "installation root". Allows something like this:
>> >
>> > using gcc : 4.0 : <root>/usr/opt/gcc4.1 ;
>> >
>> > Those parameters are mutually exclusive with "command".
>>
>> Please, please, please, let's dispense with the angle brackets in our
>> code and in our thinking.
>>
>> using gcc : 4.0 : root=/usr/opt/gcc4.1 ;
>>
>> works great.
>
> I'm just trying not to mix that change with this discussion, as <> -> = is 
> orthogonal change (which I like too).

Oh, I thought that change was implemented long ago.

Well, when discussing changes to the user interface, I still think we
should adopt it. It changes the look and feel of the things we are
discussing.

> Yes, as I indicate somewhere below. And I REALLY want somebody else to say if:
>
> configure msvc : : foo/bar ;
>
> should be same as
>
> configure msvc : : command=foo/bar ;
>
> or 
>
> configure msvc : : path=foo/bar ;
>
> or 
>
> configure msvc : : root=foo/bar ;
>
> And note that this decision should be the same for all toolsets.

I think the latter one is the only one that's reasonably orthogonal.
To me it feels wrong to name one particular thing beneath the
installation directory, which might even be several levels down,
without explicit specification.

>> > 6. "command-line" -- the exact string to use for compiler invocation. Use
>> > of this parameter disables any automatic prefixes and suffix.
>> >
>> > Basically, needed to give user full control over command line, that
>> > will be
>> >
>> > $(value of prefix)
>> > $(value of command-line) <options added by V2> files
>> > $(value of suffix)
>> >
>> > as opposed to what msvc does in common case:
>> >
>> > .......vcvars32.bat
>> > $(value of command) <options added by V2> files
>> > something else.
>>
>> We may need to allow some special syntax in command-line so that $(<)
>> and $(>) can be processed in a particular way. After all, even in the
>> simplest cases of compilation you need "-o $(<)" to appear as a
>> unit. 
>
> I was thinking that -o will be added by V2 unconditionally.

Just imagine that you need a similar flag prefix for the input files
to some tool. Then there's no order at the end of a line where you
can place all the targets/sources.

>> Another option, which I begin to like better, is to allow the 
>> user to specify a rule that gets invoked to construct the command
>> line.
>
> You mean:
>
> actions my_command_line
> {
> compile_it -o $(<) $(>)
> }
>
> configure msvc : my : action=my_command_line ;
>
> ? That would indeed be good. 

That's the general idea.

>> > 2. What happens with " && rm $(RSP)" in msvc when "command-line" is
>> > specified. Is it removed or not?
>>
>> Maybe we need the builtin RSP handling we discussed earlier. However,
>> if we really want to give the user control over the command, she'll
>> need to be able to control the contents of the RSP file as well.
>
> She can use
>
> rule my_command_line ( ........ )
> {
> // Generate response file 
> }
>
> just like msvc.jam does at the moment.

Okay.

>> > Speaking of (2) the feature is fine, but:
>> > 1. I don't want "import msvc-config ; " syntax. We need a clean
>> > interface. 2. It's possible to do such auto-configuration with
>> >
>> > using msvc ;
>> >
>> > but I'm not sure if ordinary users want to have all installed toolsets
>> > configured. Opinions?
>>
>> How could it hurt to have them configured? It costs nothing
>> AFAICT!
>
> Except execution time. IIRC, SCons used to search for all tools it
> knows about and it was a performance problem. OTOH, we'll be
> searching just for a few compilers, and not for bison/lex/f77 and
> whatnot.

Surely we can auto-configure everything that can be detected using the
windows registry?

>> > Say site-config.jam has "using gcc ; " and "user-config.jam" has
>> > "using gcc : 4.0 ; ". Now this causes an error, because V2 does not know
>> > if plain "gcc" is 4.0, or not, and so user can build two different
>> > variants that are in fac the same.
>> >
>> > There are several possible solutions:
>> > 1. Forget about site-config.jam, use only user-config.jam. But the same
>> > situation can happen with user-config.jam and Jamroot (yes, Jamroot can
>> > contain "using" call).
>> >
>> > 2. Extract gcc version via SHELL when "using gcc" is invoked and either
>> > unconditionally add it to target path, or detect that "using gcc : 4.0"
>> > uses the same version number and forget about previous "using gcc ;"
>> >
>> >
>> > Opinions?
>>
>> I amend my former opinion with the idea that #2 above might be a good
>> idea.
>
> #2 has to alternatives inside it:
> - add '4.0' to target path unconditionally
> - add '4.0' only if "using gcc : 4.0 " is later found.
>
> Which one would you like? 

I don't think it matters very much.

> Also, won't execution of compiler each time V2 is run be slow?

Maybe; I don't know. Convenience first, optimizations later. People
who care can always specify paths or versions explicitly.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com