Re: The right configuration mechanism

From: David Abrahams (dave_at_[hidden])
Date: 2005-08-05 10:30:14

Vladimir Prus <ghost_at_[hidden]> writes:

> [resend, previous message did not appear on gmane]
>
> I would like to make the final attempt to settle on the right approach
> to configure toolsets. I'd appreciate comments from everybody on the list!
> It's the last time that we can tweak the syntax.
>
> There are three issues to consider: explicit syntax and auto-detection and 
> site-config.
>
> Explicit syntax.
> ----------------
>
> At the moment, user can configure toolset manually like this:
>
> using msvc : 7.1 : "C:/Program Files/Microsoft Visual XXX NNN/bin/cl.exe" ;
> using gcc : 3.4 : "distcc g++" ;
>
> As we've discussed with Dave, there are some subtle issues.
>
> 1. The syntax of the "command" argument is not well defined. Say, is 
> g++ && echo 'Compiled OK' allowed?
> 2. Some toolsets add prefixes and postfixes. Say, vcvars32.bat invocation
> for msvc. It's not controllable in any way.
> 3. For some toolsets it's convenient to specify full binary filename, for some
> path or "install root" is more convenient.
>
> So, it's proposed to introduce a bunch of named parameters:
>
> 1. "command" -- the name of compiler binary with optional path. Allows to 
> write
>
> using gcc : 4.0 : g++-4.0 ;
> using gcc : 4.0 : /usr/opt/gcc4.1/bin/g++-4.1 ; 
>
> This is just like now, but with explicit "command" name.
>
> 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.

> Those parameters are for cases where toolset does not have a single "main" 
> binary, or just where it's more convenient for user to specify path.

We still have some disagreement about which should be the default that
takes effect with no parameter name, though ;-)

> 3. "c++", "cc", "link" -- parameters to give exact names of compiler
> components.
>
> using gcc : : path=/usr/bin c++=g++-4.0 ;

Better!

> 4. "prefix" -- a string to be added before compiler invocation, for example:
>
> using gcc : : prefix="distcc" ;
>
> will cause "distcc g++" to be invoked in build actions.
> 
> 5. "suffix" -- likewise. 

We might also want c++-prefix, link-suffix, etc.

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

> Unclear questions are:
> 1. Do we really need "c++" parameter.

Yes.

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

> There's also open question if we should retain the current syntax, where
> second parameter is taked as a command, or change it so that second parameter 
> is path, or install root. 

:) That has my vote.

> We talked about renaming "using" to "configure",
> so such change can be made without breaking compatibility.

I never thought of that advantage of the name change, but I like the
idea.

> Auto-detection
> --------------
>
> If I understand correctly, the point of msvc-config experiment was two
> 1. Use registry for configuration
> 2. Configure all found toolsets.
>
> Speaking of (1), if Windows users find that method to be better, then I don't 
> know why not change msvc.jam accordingly.
>
> 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!

> 3. There are two interface approached to request configuration of all 
> versions:
>
> using msvc : all ; # 'all' is a special value for version.
> configure-all-versions msvc ;
>
> If "using" is renamed to "configure", then some word having "configure" as 
> part can be used to request configuration of all versions. Say: 
> "auto-configure", "configure-all", "configure-all-versions".

I vote no. There's no reason not to configure everything if no
versions are specified.

> Also, if we have
>
> using gcc : 4.0 ;
>
> we probably need to look for "g++-4.0" in path, not just for "g++".

Yes, that's another issue.

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

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