Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-08-05 07:35:38

[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

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

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

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:

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


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

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


- Volodya

Vladimir Prus
Boost.Build V2:

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