Den 2010-09-02 16:08 skrev Peter Rosin: > Den 2010-09-02 16:02 skrev Charles Wilson: >> 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 >> '^...@[[:alpha:]]:[/\]' are understood as dos-style abspaths. >> >> I'll look into that. > > That would be nice indeed. > >> 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? > > The rest is handled by the compile script (in automake) in my case...
Ahh, now I see what you mean here. If we have already transformed -o /bob/... into -FoC:/bob/... and then MSYS thinks it's a path and in turn makes it into -Foc;c:\msys\1.0\bob\..., then we're really up shit creek... But luckily, MSYS apparently does not handle -FoC:/bob/... the same way it handles @C:/bob/..., so we are safe... I have verified that "cl -c -FoC:/foo.obj C:/foo.c" does indeed create a c:/foo.obj file. Cheers, Peter
