The right configuration mechanism

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-08-04 05:15:54

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

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.

3. "c++", "cc", "link" -- parameters to give exact names of compiler
components.

using gcc : : path=/usr/bin c++=g++-4.0 ;

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. 

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.

Unclear questions are:
1. Do we really need "c++" parameter.
2. What happens with " && rm $(RSP)" in msvc when "command-line" is specified.
Is it removed or not?

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. We talked about renaming "using" to "configure",
so such change can be made without breaking compatibility.

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

Also, if we have

using gcc : 4.0 ;

we probably need to look for "g++-4.0" in path, not just for "g++".

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?

- Volodya

-- 
Vladimir Prus
http://vladimir_prus.blogspot.com
Boost.Build V2: http://boost.org/boost-build2