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

[Ralf Wildenhues]

* Peter Rosin wrote on Wed, Jun 23, 2010 at 09:57:54AM CEST:
> For those that didn't know, we have these cl options to play with:

One reference: http://msdn.microsoft.com/en-us/library/19z1t1wy.aspx

> My patches went with -TP/-TC. IIUC AC_FC_SRCEXT outputs FCFLAGS_ext which
> can be used as this:
> 
>           foo.o: foo.f90
>                $(FC) -c $(FCFLAGS) $(FCFLAGS_f90) '$(srcdir)/foo.f90'
> 
> which is a closer match for -Tp/-Tc but I don't know if the missing space
> is going to be an issue for other potential future users of the macro. I.e.
> can you portably store a trailing space in a makefile variable so that the
> following is a usable construct for something that needs e.g. say
> CXXFLAGS_cc="-cpp "?
> 
>      $(CXX) -c $(CXXFLAGS) $(CXXFLAGS_cc)'$(srcdir)/foo.cc'

It is possible I think, with something like
  empty =
  trailing_space = foo $(empty)

But for packages using automake, this is not an issue at all.  Look at
automake.in, it controls how per-language compile lines will look like:
  $sourceflags{'.' . $suffix} = '$(FCFLAGS_' . $suffix . ') '

Note the trailing space, that gets expanded at automake run time, not at
make run time.

> Another issue that doesn't translate directly from the Fortran case is that
> one extension we /may/ want to cover is .c++, and I don't expect that
> CXXFLAGS_c++ is very good as a variable name.

Flattening of the suffix is trivial in automake, too.

This would all just be an issue for packages using Autoconf but not
Automake, writing compile lines in Makefile.in files themselves.

> 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
>         ;;

Are you sure there can't be another argument matching these endings?
  -Dfoo=bar.cc

Does cl accept any options with separated arguments, i.e., $2 has the
argument to $1?  We may have to start parsing these right.

Other than that, I don't see problems with the 'compile' hack approach.
Please keep this change (and associated testsuite additions) separate
from the other patch though, for clarity.

> I'm not adding these references about what happened when in these messages
> to make everyone apologize and generally feel bad. I add them to simplify
> review and to save others from digging in history that I have already been
> through.

Yeah, and that's good, too.

Thanks,
Ralf