id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
131	Toolset command configurability too limited	Dave Abrahams	somebody	"== Example 1 ==

I have a situation where I need to run the vc8 toolset and
VS80COMNTOOLS is not already set in the environment.  This is, in
fact, what you get when you open a cygwin shell.  When VS80COMNTOOLS
isn't set, vcvarsall.bat fails.  I thought I could simply:
{{{
  msvc.configure : ""<setup>set \""VS80COMNTOOLS=C:\\Program Files\\Microsoft Visual Studio 8\\Common7\\Tools\\\\"" && ""C:\\Program Files (x86)\\Microsoft Visual Studio 8\\VC\\vcvarsall.bat\""
}}}
in my user-config.jam, but alas, BBv2 doesn't give me complete control
over the setup command.  Instead, it inserts ""call cmd /C /S"" before
the setup command and > nul afterwards.  Even if it did, the problems
of correct quoting through the layers of bjam, cygwin bash, and
finally CMD.EXE, are hard to come to grips with.


IMO, really, when invoked from *nix, the setup, etc., ought to be
piped into a command shell as follows:
{{{
  cat <<EOF | CMD.EXE /Q 2>&1
  @ECHO OFF
      ... setup command here ...
      ... tool invocation here ...
  EOF | ...whatever filter you like...
}}}
That would drastically simplify issues of command quoting, among other
things.  

== Example 2 ==

Passing a command like
{{{
  PATH=c:\\cygwin\\bin;%PATH% ""&&"" g++
}}}

to {{{using gcc}}} fails miserably, as the toolset is only prepared to deal with paths to executables rather than actual commands.  However, AFAICT our documentation gives no hint that you can't  /really/ use arbitrary commands. It would be better to open the field and let the user really pass whatever command he likes as long as it eventually invokes g++ and any following arguments get passed through to g++.  I've done that for Python, and it works nicely, so it is practical."	defect	new	major		component1