Re: MSVC: MSVC needs a hint to force it to compile either as C or C++.

[Charles Wilson]

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