Re: [PATCH] [cygwin]: Add cross-compile support to cwrapper

[Charles Wilson]

Peter Rosin wrote:
> Might I suggest
> [snipped: modify func_msys_to_win32 to convert all \\ to /, rather than
> converting all / to \\]
> instead? And perhaps a similar change to func_wine_to_win32_path, but
> I have not tested that.

I knew there was a reason I did it this way (and using cygpath -m
instead of cygpath -w was an oversight):
Roumen Petrov said here
http://lists.gnu.org/archive/html/bug-libtool/2008-04/msg00167.html
> Although the test succeed with slash(/) in path I think that on host
> it will fail due "./" in paths. I think that winapi work with slashes
> in path only if they do'nt appear after dot.

However, if Roumen is wrong about that, then...

> The reason I'm requesting this change is that a later patch introducing
> func_to_tool_path which reuses these functions will need to quote
> paths for eval in some places if they might contain backslashes, and
> quoting for eval will cost forks on sane setups that don't deserve to
> lose.

...if we CAN use '/' always, I'd like to.  Have you ever heard that ('/'
is OK except after '.') before? I hadn't.

I have heard that (a) in NT kernel other low-level calls it is
mandantory to use backslash, and (b) when using unicode versions of
w32api functions you have to use the unicode backslash, not the unicode
forward slash. (Also, when using global path syntax ('\\?\' + stuff) you
have to use backslashes).

However, that doesn't apply here, does it?  In the wrapper, at least,
we're using _spawnv() which is neither kernel/low-level nor unicode.
However, that argument doesn't apply for your MSVC usages of the
conversion functions.

> Also, I'm curious, what is the difference between mingw and win32 in this
> context, i.e. why not name the function func_cygwin_to_win32_path_convert?

grep -E '^func' libltdl/config/ltmain.m4sh | grep win32
func_win32_libid ()
func_wine_to_win32_path ()
func_wine_to_win32_pathlist ()
func_msys_to_win32 ()
func_win32_import_lib_p ()

grep -E '^func' libltdl/config/ltmain.m4sh | grep mingw
func_msys_to_mingw_path_convert ()
func_cygwin_to_mingw_path_convert ()
func_nix_to_mingw_path_convert ()
func_msys_to_mingw_pathlist_convert ()
func_cygwin_to_mingw_pathlist_convert ()
func_nix_to_mingw_pathlist_convert ()

Ignoring func_win32_libid  and  func_win32_import_lib_p, it is an odd
mix, isn't it?  For the latter group, I was trying to use a consistent
"$build" to "$host" nomenclature -- and I felt that using "win32" in the
"$host" position was confusing, because all of cygwin/msys/"native" are
"win32".

For the former group:
func_wine_to_win32_path ()
func_wine_to_win32_pathlist ()
func_msys_to_win32 ()

Uh, well, see, I was, err, they're all "utility" functions that are
called by the actual $host_to_$build_convert functions, so, er, that's
why they are named *_win32, and not *_mingw. Yeah, that's the ticket.

Although, if you look in func_nix_to_cygwin, you'll see:
    func_wine_to_win32_path "$1"
    func_cygpath -u "$func_wine_to_win32_path_result"
If func_wine_to_win32_path were called func_wine_to_mingw_path, it'd be
 a little odd to see it invoked inside func_nix_to_cygwin, because mingw
per se is not involved in that case (unix cross to cygwin) at all. So, I
don't think these three functions should be renamed to *_mingw.

I guess I could see the case for renaming all of the
*_to_mingw_path[list]_convert functions to
*_to_win32_path[list]_convert, since they will be heavily used by your
MSVC stuff -- which doesn't involve "mingw" per se at all.

However, IF you are passing converted paths to msvc compiler tools as
command line arguments, and IF they are relative paths ... they might
not like them.  I know that cmd.exe utilities refuse to accept paths
like that:

$ dir Desktop/ITP
Invalid switch - "ITP".

--
Chuck