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

[Charles Wilson]

Roumen Petrov wrote:

> >  # func_to_host_path arg
> [SNIP]
>
>
> >  # ARG is the path (on $build) that should be converted to
> >  # the proper representation for $host. The result is stored
> > @@ -2546,11 +2553,28 @@ func_to_host_path ()
> >              func_to_host_path_result=`echo "$func_to_host_path_tmp1" |\
> >                $SED -e "$lt_sed_naive_backslashify"`
> >              ;;
> > +          * )
> > +            # Unfortunately, winepath does not exit with a non-zero
> > +            # error code, so we are forced to check stderr for an
> > +            # error message. On the other hand, if the command is not
> > +            # found, the shell will set an exit code of 127. So we
> > +            # must check for both, which explains the odd construction:
> > +            func_to_host_path_winepath_stderr=`winepath -w "$1" 
> >  >/dev/null 2>&1`
> > +            func_to_host_path_winepath_exitcode=$?
> > +            if test "$func_to_host_path_winepath_exitcode" -eq 0 &&\
> > +               test -z "${func_to_host_path_winepath_stderr}" ; then
> > +              func_to_host_path_tmp1=`winepath -w "$1"`
> > +              func_to_host_path_result=`echo 
> > "$func_to_host_path_tmp1" |\
> > +                $SED -e "$lt_sed_naive_backslashify"`
> > +            fi
> > +            ;;
> [SNIP]
>
> So it winepath fail to convert a build-system path it output only LF on 
> standard output(stdout).
> I cannot confirm that exists relation: 'non-empty' stderr output and 
> path-translation failure.
>
> My point of view is that check for 'empty' stdout is enough as 
> indication for translation-failure.

The problem with that is, bash puts the following on stdout -- NOT 
stderr -- if it cannot find winepath:
bash: winepath: command not found

So, at the very least, we have failure if either
  stdout is empty
or
  exit code is nonzero

Try replacing the section above with:

          * )
            # Unfortunately, winepath does not exit with a non-zero
            # error code, so we are forced to check the contents of
            # stdout. On the other hand, if the command is not
            # found, the shell will set an exit code of 127 and print
            # *an error message* to stdout. So we must check for both
            # error code of zero AND non-empty stdout, which explains
            # the odd construction:
            func_to_host_path_tmp1=`winepath -w "$1" 2>/dev/null`
            func_to_host_path_winepath_exitcode=$?
            if test "$func_to_host_path_winepath_exitcode" -eq 0 &&\
               test -n "${func_to_host_path_tmp1}" ; then
              func_to_host_path_result=`echo "$func_to_host_path_tmp1"|\
                $SED -e "$lt_sed_naive_backslashify"`
            fi
            ;;

And let me know if that works better for you.

> Fine with the fail-back change in func_to_host_path .
> But I would like to note that this addition always lead to non-empty 
> func_to_host_pathlist_result in func_to_host_pathlist. So I think that 
> the then clause in check "if test -z "$func_to_host_pathlist_result" ; 
> then" is reachable only if function argument $1 if empty.

Yes, and that's ok. It's to allow things to continue to work "as they 
are" even if we add additional $host/$build pairs to 
func_to_host_path[list], and those other pairs explicitly force empty 
return values.

> About "# Now, add the leading and trailing path separators back" from 
> func_to_host_pathlist:
> By default wine search in current directory and path-list like ";m:\..." 
>   is equal to "m:\...". Same for trailing separator.
> In this case the new code simplify script and it is fine with me.

Yes, but the case I'm thinking about, libtool converts two different paths:

/path/to/destdir/inst/app

and

:/path/to/destdir/inst/lib:/path/to/builddir/.libs:

and then joins the results. So, if we aren't very careful with the 
leading/trailing :, we'll end up with

C:\path\to\destdir\inst\appC:\path\to\destdir\inst\lib;C:\path\to\builddir\.libs
                          ^^^
oops.


--
Chuck