Boost logo

Boost-Build :

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


> > > 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]().


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

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