Re: cl -c -o trouble in libtool am-subdir.at

[Ralf Wildenhues]

Hi Peter,

* Peter Rosin wrote on Wed, Jan 21, 2009 at 09:06:22PM CET:
> For some years now, I've been working on and off on adding MSVC
> support w/o wrapper scripts to libtool (see the pr-msvc-support
> branch in libtool git) and have run into an issue that has been
> brought up here before.
>
> http://lists.gnu.org/archive/html/automake/2007-06/msg00083.html
>
> I was trying to fix the am-subdir.at test in the libtool testsuite.
> That test uses C++ and compiles in subdirs, so it's really no big
> surprise that MSVC is in trouble there.
>
> In short, MSVC w/o wrapper needs AM_PROG_CXX_C_O for that test to work
> (a few other minor tweeks might also be needed, methinks...).
>
> Can such a macro be added to automake, please?

I'm thinking that this issue could be fixed more efficiently by
parametrizing '-o '.  IIRC then cl accepts /OUT:FILE or -out:FILE
(the latter is better to avoid MSYS path translation) or so, right?
Then the alternate settings
  minuso = -out:
  minuso_CXX = -out:

  minuso = -o ''
  minuso_CXX = -o ''

should work (I don't know of a good way to get a trailing space through
to make without such a quoting helper construct).

Upsides of this approach:
- avoid another wrapper script for MSVC, thus faster.

(Possible) downsides of this approach:
- works only for MSVC, not for old C and C++ compilers (the only C++ one
  we know of is the SCO one), and old Fortran compilers,
- users' Makefile.am scripts may need adjustment (when users have added
  compile rules)
- the non-MSVC rules will look uglier.
- On some systems, GNU make may start forking a shell for executing
  compile commands where it didn't do so before.  For example, the
  current construct_command_argv_internal heuristic would make the
  appearance of single quotes start a shell for DOS (but not for unixy
  systems).

I'm not sure whether this is worth the hassle.  If you have better
ideas (e.g., to avoid some of the downsides), I'm all ears.  All other
things being equal, the GNU stance of not pessimizing code in order to
support w32 better would of course speak against this, too.

Otherwise, yes, I can dig up those AM_PROG_*_C_O patches.  Their
downside for non-MSVC is another configure test, and another macro
for users to put in configure.ac.

Cheers,
Ralf