libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] msvc: eliminate spaces in the library search path.


From: Charles Wilson
Subject: Re: [PATCH] msvc: eliminate spaces in the library search path.
Date: Tue, 21 Sep 2010 14:08:33 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4

On 9/21/2010 1:33 PM, Ralf Wildenhues wrote:
> Hi Peter,
> 
> * Peter Rosin wrote on Tue, Sep 21, 2010 at 09:37:16AM CEST:
>> I know it's late for the release, but I'd like to squeeze this one in
>> too, if at all possible. After all, it doesn't affect anything but MSVC.
> 
> I have questions:
> 
> What does Charles have to say to this?

Well, in principle -- so long as this code is activated only when $CC is
MSVC -- the patch as revised is fine with me.

> What is $LIB?  Is this an API you just made up?  If not, where is it
> documented?  Hmm, we used it before, so I guess that's not new.

LIB and INCLUDE are MSVC's mechanisms for setting search paths; it's not
something we libtoolers picked.

>> +      do
>> +        IFS=$lt_save_ifs
>> +        # Let DOS variable expansion print the short 8.3 style file name.
>> +        lt_path=`cd "$lt_path" && cmd //C "for %i in (".") do @echo %~si"`
> 
> Can you explain what this command does?  I mean, no need to change the
> patch, but I don't understand the %~si syntax and I can only infer the
> %i and (...) bits, but can't tell whether they are correct, work by
> accident, or something else.  I'm willing to believe you, but it would
> be nice to know for sure.

See http://thread.gmane.org/gmane.comp.gnu.mingw.user/34276

> Can the command fail?

Sure -- if lt_path doesn't exist.  I don't know if that is an issue in
this particular case.  It will also fail on Win9x (where cmd.exe doesn't
exist, and command.com is supposed to be used).  However, we already
have that "problem" in func_convert_core_msys_to_w32.

One workaround would be to use the %COMSPEC% variable in both cases,
but...I'd rather go with cmd in both places, and then worry about
%COMSPEC% after the release, and only if we get complaints.

>> +        sys_lib_search_path_spec="$sys_lib_search_path_spec $lt_path"
>> +      done
>> +      IFS=$lt_save_ifs
>> +      # Convert to MSYS style.
>> +      sys_lib_search_path_spec=`$ECHO "$sys_lib_search_path_spec" | sed -e 
>> 's|\\\\|/|g' -e 's| \\([[a-zA-Z]]\\):| /\\1|g' -e 's|^ ||'`

Yes, sadly msys does not provide a program analogous to cygpath.  So, we
can go msys->win32 by exploiting msys's autoconvert behavior (by running
a "native" win32 program "cmd.exe" with the args to be converted).  But
we can't go the other direction -- so, fun with sed scripts.

The downside of this is that only the "standard" representation of paths
will be used (e.g. C:/foo -> /c/foo, etc).  If there are any special
mount points defined in MSYS's /etc/fstab -- for instance

        C:\PROGRA~1\MICROS~2    /vizstudio

You'll get /c/PROGRA~1/MICROS~2/whatever instead of /vizstudio/whatever.
 In practice, this should make no difference -- and there really isn't
any way around it, without improvements/additions to MSYS.

>> +      ;;
>> +    cygwin*)
>> +      # Convert to unix form, then to dos form, then back to unix form
>> +      # but this time dos style (no spaces!) so that the unix form looks
>> +      # like /cygdrive/c/PROGRA~1:/cygdr...
>> +      sys_lib_search_path_spec=`cygpath --path --unix "$LIB"`
>> +      sys_lib_search_path_spec=`cygpath --path --dos 
>> "$sys_lib_search_path_spec"`
>> +      sys_lib_search_path_spec=`cygpath --path --unix 
>> "$sys_lib_search_path_spec" | $SED -e "s/$PATH_SEPARATOR/ /g"`
> 
> Can any of the cygpath commands fail?
> What about LT_CYGPATH?

If $build_os is cygwin, then cygpath.exe IS in the $PATH (or there is
something *extremely* broken about your cygwin installation).  So, for
$build=cygwin, we can invoke cygpath directly.  LT_CYGPATH is used when
$build != cygwin, but there is a cygwin "somewhere" that is accessible.

We can't use the func_conv functions here, because we're (a) going
"backwards" in two cases, and (b) using the --dos flag instead of
--windows or --mixed even when we're going in the "right" direction.

>> +      ;;
>> +    *)
>> +      sys_lib_search_path_spec="$LIB"
>> +      if $ECHO "$sys_lib_search_path_spec" | [$GREP ';[c-zC-Z]:/' 
>> >/dev/null]; then

What if there is only a single directory in the path spec?  Then there
won't be a ';', and we'll use the else clause -- is that the right thing
to do?

>> +        # It is most probably a Windows format PATH.
>> +        sys_lib_search_path_spec=`$ECHO "$sys_lib_search_path_spec" | $SED 
>> -e 's/;/ /g'`
>> +      else
>> +        sys_lib_search_path_spec=`$ECHO "$sys_lib_search_path_spec" | $SED 
>> -e "s/$PATH_SEPARATOR/ /g"`
>> +      fi


--
Chuck



reply via email to

[Prev in Thread] Current Thread [Next in Thread]