* 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
