libtool-patches
[Top][All Lists]
Advanced

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

Re: [PATCH 0/7] Support for toolchains that are not $host-native.


From: Charles Wilson
Subject: Re: [PATCH 0/7] Support for toolchains that are not $host-native.
Date: Thu, 02 Sep 2010 10:02:09 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666

On 9/2/2010 9:06 AM, Peter Rosin wrote:
> However, my previous suggestion with a naive_slashify instead of
> naive_backslashify doesn't work either since MSYS turns @c:/foobar into
> @c;c:\msys\1.0\foobar (or something similar, that was from memory) which
> we must avoid at all cost. cygpath -m (instead of -w) is fine on Cygwin
> though since Cygwin doesn't clobber @c:/foobar "for us".
> 
> Maybe we can work around this by sanitizing the input files in ar-lib,
> but that seems a bit horrible to me... I'll see if I can fix this
> somehow. Suggestions welcome.

Actually, I think MSYS's heuristic for determining whether an argument
contains a path -- and whether that path is already a dos-style one --
should be improved so that args which match the regex
'address@hidden:alpha:]]:[/\]' are understood as dos-style abspaths.

I'll look into that.

Oh, wait.

We'd also need to add exceptions for all of MSVC's command switches,
which prohibit spaces between the switch and that path: -FoC:/bob/,
-FeD:/fred, etc.  Ick.

I dunno if that's worth the effort -- or if it would even be accepted.
After all, MSYS's reason for existence is to support MinGW, not MSVC...
I could justify adding the '@' heuristic, because MinGW ar can use it,
but the rest...

What do you think, Peter?

--
Chuck



reply via email to

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