Re: [Boost-build] Changes to GCC toolset init?

Subject: Re: [Boost-build] Changes to GCC toolset init?
From: Moritz Hassert (mhassert_at_[hidden])
Date: 2010-09-30 05:57:36

Hi,

> > > using gcc : mw4 : "set PATH=C:/MinGW/bin;%PATH% &&
> > > C:/MinGW/bin/g++.exe"
> > > 
> > > : <linkflags>-enable-auto-import ;
> > > 
> > > Produces:
> > > 
> > > M:/data/boost/trunk/tools/build/v2/tools\gcc.jam:77: in gcc.init from
> > > module gcc
> > > 
> > > error: toolset gcc initialization:
> > > error: provided command 'set PATH=C:/MinGW/bin;%PATH% &&
> > > C:/MinGW/bin/g++.exe' not found
> > > error: initialized from C:\cygwin\home\john\user-config.jam:43
> > 
> > I don't think specifying anything like "set PATH=C:/MinGW/bin;%PATH% &&
> > C:/MinGW/bin/g++.exe" for the command could ever work. The command string
> > can only contain the binary to run and its optinal path.
> > 
> > If you ever need to set an environmnet variable for some other reasons,
> > you should encapsulate everything in a bash-script or batch-file.
> 
> Actually, it's supposed to work. I have tested that say "distcc g++" still
> works with the patch, but it seems that "set" might be tricky to recognize.

Does GLOB in "check-tool-aux" take more than one pattern or does it ignore all 
but the first?
In the former case, must all be found? "set" and "PATH=..." can't be found.
In the latter case,  "set" is not found but "distcc" is.

Or does $(command:D) evaluate to true for Johns command string, because there 
are path separators in it?

> Maybe, the right approach is just try running to command, and remove
> all looking around in PATH?

Yes indeed, that would be the best approach. That way, it's totally up to the 
OS how run a command and where to find it. No need for any ".exe" appending and 
such on windows, no checking for an executable bit on *nix (which is currently 
not done!), and no extra work when porting to some weird OS with a completely 
different command running logic.

The only pitfall is possible side effects of the given command. One could 
specify some script that changes something on disk when it's executed. It will 
be executed during configuration, even if that toolset is never used. That may 
be unexpected to the user.
For toolset gcc it makes no real difference, as later the command will be run 
anyhow to dump version and machine. I don't no if that's the case for all 
toolsets that use rule get-invocation-command[-nodefault]().

Greetings
Moritz

-- 
--
AB+M GmbH 
Haid-und-Neu-Straße 7
76131 Karlsruhe
Telefon: [phone]
Telefax: (0721) 66488-18
Geschaeftsfuehrer: Dipl.-Inform. Christopher Asp
Amtsgericht Mannheim HRB 105845