On 6/23/2010 3:57 AM, Peter Rosin wrote: > For those that didn't know, we have these cl options to play with: > > /Tp<source file> compile file as .cpp /Tc<source file> compile file as .c > /TP compile all files as .cpp /TC compile all files as .c > > (but using - instead of / to not go insane immediately)
Yes, cl accepts switches with either '/' or '-' introductory characters. For our purposes, it's almost required to use '-' rather than the Microsoft standard '/', because for "native" use, our shell is an msys shell, and MSYS does interesting things when exec() or spawn() functions are called... In this case, one "interesting" thing is that MSYS has a heuristic that any command line arguments that start with '/' are presumed to be (posix) paths, and if the to-be-exec'ed program is a native one, then the argument will be converted to a DOS path. E.g. /Tpbob.cpp == C:/pwd/Tpbob.cpp /TcC:/path/to/fred.cpp == C:/TcC:/path/to/fred.cpp /TP == C:/TP /TC == C:/TC This is clearly bad...and can be avoided by always using '-' (or by 'doubling' the leading slash, which turns off MSYS's path conversion logic: msys path.cc: // // Multiple forward slashes are treated special, // Remove one and return for the form of //foo or ///bar // but just return for the form of //server/share. // but (a) this would break for //TcC:/a/path because the fact that there are additional '/' other than the leading sequence means that the first, doubled pair would not be translated into a single leading slash, and (b) that's just more than we want to deal with, here, since '-' will do what we want.) > My patches went with -TP/-TC. OTOH, //TP and //TC would work just as well, with an MSYS shell. But I think your choice (both using '-' and using the "capital" variants of these switches) is a good one, because... > To me, it seems way easier to do it in compile. Can it take the clutter? > (which would be something like this added to the proposed compile script) > > *.C | *.cc | *.cpp) > func_file_conv "$1" > set x "$@" -Tp"$file" > shift > ;; > *.c) > func_file_conv "$1" > set x "$@" -Tc"$file" > shift > ;; There is one problem with the above. -Tcrel/path/to/file will work OK, and -Tcfile-in-curdir will work. Also -TcC:/dos/path/to. But -Tc/abs/posix/path/to/file won't, because...well, another MSYS heuristic. MSYS knows about some of gcc's "path" introductory switches, like -I and -L, and will convert -I/posix/path/to/inc -L/posix/path/to/lib to -IC:/msys/1.0/posix/path/to/inc -LC:/msys/1.0/posix/path/to/lib if the gcc in question is a native application (like MinGW gcc is) [Technically, this works for any "single letter option". But MSYS *doesn't* know about cl's "path introductory switches" like -Tc or -Tp that have more than a single letter. msys path.cc: // // Check for single letter option with a // path argument attached, eg -I/include */ // So, for the path translation heuristics to work, MSYS *needs* a space between -Tc and /the/path, so that /the/path can be detected as an "absolute posix path" by itself. Unfortunately, I *think* cl requires that there be NO space between -Tc and C:/the/path. Ditto -Fo, etc. Unless you've already manually converted the path in question from posix to win32 form, the -Fo, -Tc, -Tp, and similar options won't work. The preceding is all just background, because I think Peter's patch *does* do a manual path conversion for any paths that appear together with these options. It costs an extra fork for each one, but...short of teaching the MSYS DLL about cl's huge list of multi-char options, I think Peter's approach is the only rational choice. -- Chuck