Re: [jamboost] Re: Toolset init changes: gcc, intel and sun

From: Michael Stevens (Michael.Stevens_at_[hidden])
Date: 2004-06-23 13:15:16

On Wednesday 23 June 2004 15:47, Vladimir Prus wrote:
> > Like Christopher I particularly like the change so I can run compilers
> > with prefixes. "distcc" for example.
> > So I am glad the gcc toolset does not need to call
> > "get-invocation-command" and warn.
>
> Oops! I've changed gcc to use get-invocation-command an hour ago.
No worries I am not that quick on checking out!
>
> > One possibility in this regard would be to allow
> > "user-provided-command" to contain two elements. The first element could
> > be the prefix, and the second the actual command. Only the latter would
> > be use to fine the tool path.
>
> Yes, I think this might be the right solution. We also have to figure out
> what to do with the shell -- I've just tried the "distcc g++" command and
> shell barks, just like Jürgen has said.
Yep the "distcc g++" gets used as the executable name (what would be argv[0]). 
I think the general solution to this would be to make 'command' n-element. 
That way the first element (the acutal command in any prefix) can have spaces 
in and be wrapped in "" in the action. The remaining elements (command line 
arguments to the prefix command can be used as they are in the action. I 
think this would work for all environments and shells.
The n-th element would have to be the command from which the tool path is 
derived which may be a little resticting.

>
> (Not 100% ontopic, but: we have distcc here by creating a number of wrapper
> scripts in /usr/local/bin/distcc, which just call "distcc /usr/bin/g++". In
> means that to switch distcc on it's only necessary to change PATH. This
> might not be a good solution for you......
> )
Agreed this would be a fine workaround for distcc.

>
> > The exception to this freeform rule is the 'msvc' toolset. Here the
> > 'version' parameter has meaning and is used to automagically choose paths
> > and options. I not sure of a good solution to this dichotomy !
>
> Well, we can state in docs that some toolset interpret "version" specially,
> though it's a bit backward, after making sure that all toolset interpret
> "command" in the same way ;-)
>
> I'm puzzled.
I guess msvc as a special case would be reasonable solution.
To puzzle you a bit more I have another multi-element solution! If 'version' 
is n-element then we can define the first as the only one which has semantic 
meaning to the toolset. The rest are simply freeform and the whole lot are 
concatenated together to provide the version string used as the build target.

All the best,
Michael