Mail Archives: cygwin-developers/1998/12/23/14:35:22
DJ Delorie <dj AT delorie DOT com> writes:
>
> If you do "gcc --print-file-name libgcc.a" cygwin's gcc currently
> prints the result using Win32 paths. This breaks cygwin's make. We
> were just about to change it to print posix paths, but we realized
> that it was done this way for a reason, and there are cases where it
> makes sense to print win32 paths.
I and others (notably Earnie Boyd) have this raised issue in the past
without much response from others, so I'm glad we're finally going to deal
with it.
Can you tell us why it was done? I've asked this in the past, but never
did get an answer.
> We thought about using -mcygwin or -mmingw to trigger the output type,
> but those only work for native gcc's - they won't work if the gcc is
> host=cygwin but a different target (the -m options are
> target-specific, not host-specific).
>
> My thought was that if gcc was built for a cygwin host, chances are,
> the other tools were also, so posix paths make sense, and if gcc is
> built with non-cygwin, chances are the other tools were too, so native
> paths make sense.
>
> Can anyone think of other possible solutions or caveats?
My approach may seem a bit harsh, but I believe it's quite reasonable.
Folks who want to use Cygwin hosted toolchain for whatever target should
expect posix pathnames and use tools that do the right thing. If they
want native pathname, they can simply write a simple filter (using
cygpath for example) that do the munging for them. If you consider
Windows32 to be an embedded target like I do, it all makes sense ;-)
I doubt if we can satisfy everybody, so we should just go with the right
thing (which is of course always subjective).
Regards,
Mumit
- Raw text -