[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: pr-msvc-support merge
From: |
Ralf Wildenhues |
Subject: |
Re: pr-msvc-support merge |
Date: |
Sat, 19 Jun 2010 05:38:05 +0200 |
User-agent: |
Mutt/1.5.20 (2010-04-22) |
* 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
- Re: pr-msvc-support merge, Ralf Wildenhues, 2010/06/14
- Re: pr-msvc-support merge, Peter Rosin, 2010/06/16
- Re: pr-msvc-support merge, Ralf Wildenhues, 2010/06/16
- Re: pr-msvc-support merge, Peter Rosin, 2010/06/16
- Re: pr-msvc-support merge,
Ralf Wildenhues <=
- Re: pr-msvc-support merge, Peter Rosin, 2010/06/21
- Re: pr-msvc-support merge, Charles Wilson, 2010/06/21
- Re: pr-msvc-support merge, Peter Rosin, 2010/06/22
- Re: pr-msvc-support merge, Charles Wilson, 2010/06/22
- Re: pr-msvc-support merge, Peter Rosin, 2010/06/22
- Re: pr-msvc-support merge, Peter Rosin, 2010/06/22
- Re: pr-msvc-support merge, Ralf Wildenhues, 2010/06/22
- Re: pr-msvc-support merge, Peter Rosin, 2010/06/23
Re: pr-msvc-support merge, Charles Wilson, 2010/06/19