Re: pr-msvc-support merge

[Ralf Wildenhues]

* Peter Rosin wrote on Wed, Jun 16, 2010 at 10:30:22PM CEST:
> Den 2010-06-16 20:57 skrev Ralf Wildenhues:
> >This explanation of yours lends itself nicely to a testsuite addition
> >that exercises the 'compile' script (no need to go through Autoconf or
> >Automake indirections), as in
> >   cp $testsrcdir/../lib/compile .
> >   ./compile ... "weird\path\that\has\backslash-t.c" ...
> >   ...
> 
> If you create a script named .../cl that just dumps args you can test
> that compile does the expected thing w/o having the real cl available.

Yep, good idea.

> >I have a more general question though: for all of 'cmd //c', cygpath,
> >and wineconv, are their conversions idempotent?  I.e., when I insert a
> >converted path, do they produce the same path again (a testsuite
> >addition could try to verify this).  This might be necessary because we
> >have other pending patches for libtool that convert names to host format
> >there already, and those should not be broken.
> 
> If you look closely, the path conversion is only invoked if the path -
> errmmh file - starts with a single forward slash, so we should be
> completely safe if we are given pre-converted file names.
> 
> (I find it difficult is it to not say "path" when I refer to either
>  a directory or a file name, and so do you...)
> 
> The "cost" here is that users with weird mount tables (where a relative
> file name does not mean the same thing in posix-land as it does in
> windows-land) will not get the correct outcome.
> 
> But I really didn't do that optimization to cater for pre-converted
> file names, I did it to save a fork in the common case (relative file
> names and a "sane" mount table).
> 
> So, to answer you question, I think that the MSYS converter is safe
> with Windows file names. I also think cygpath is generally safe, but
> I'm sure there are also moronic cases which will not work (directories
> named C: etc). For winepath I don't know.

OK, that sounds good enough to me.

> >>+       *.o | *.[oO][bB][jJ])
> >
> >What about *.[oO]?  Is that something we need to take into account?
> 
> I thought about that, but decided not to because .o is only there to
> handle the (theoretical?) case where the project is totally unixy (not
> even using $objext) and in that case the likelihood of .O seems very
> remote. I simply didn't think .O would ever appear. What do you think?

Agreed.

> Should I keep attaching the "current" version of the patch?

Sure, but the patch is good to go once copyright papers are through,
with testing added.

Thanks,
Ralf