Re: [jamboost] Re: The right configuration mechanism

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 ;

or 

configure msvc : : path=foo/bar ;

or 

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

Probably.

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

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

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

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.

Ok.

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

#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?

- Volodya

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