From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-08-12 05:22:48
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).
> > 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 ;-)
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 ;
configure msvc : : path=foo/bar ;
configure msvc : : root=foo/bar ;
And note that this decision should be the same for all toolsets.
> > 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.
> 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
I was thinking that -o will be added by V2 unconditionally.
> Another option, which I begin to like better, is to allow the
> user to specify a rule that gets invoked to construct the command
compile_it -o $(<) $(>)
configure msvc : my : action=my_command_line ;
? That would indeed be good.
> > 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.
> > 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
> > 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!
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.
> > 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
#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? Also, won't execution of compiler each time V2 is
run be slow?
-- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build V2: http://boost.org/boost-build2
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk