From: David Abrahams (dave_at_[hidden])
Date: 2003-12-01 16:20:57
Beman Dawes <bdawes_at_[hidden]> writes:
> At 08:33 PM 11/29/2003, David Abrahams wrote:
> >Jeremy Maitin-Shepard <jbms_at_[hidden]> writes:
> >> I suppose it is partially a matter of user preferences.
> >I'd put it more strongly than that.
> >> My impression though was that one of the purposes of cygwin is to
> >> provide some amount of POSIX support, and that c: can by accessed at
> >> /cygdrive/c, for example.
> >> With Windows paths, calling "complete" on a cygwin path like
> >> "/cygdrive/c" will bring unexpected results.
> >> It seems though that at least some Windows users use cygwin for
> >> development purposes primarily for a better shell, rather than for
> >> POSIX support, and thus expect to use standard Windows paths.
> >In fact, the cygwin filesystem view, with the drives at
> >/cygdrive/[a-z], is its primary way of dealing with paths. All of the
> >cygwin tools support it. Some additionally support Windows paths, but
> >not all - that should be considered a secondary/optional approach.
> >For example, scp needs colons as part of its syntax for remote access,
> > $ scp c:/tmp/fu .
> > ssh: c: no address associated with name
> I guess the problem is that Boost.Filesystem doesn't currently have
> a compilation mode that says "compile this to target the cygwin
> Just using defined(__CYGWIN__) doesn't work, since it gets defined
> for all gcc compiles (at least if cygwin is installed on the
Not if you're passing -mno-cygwin or using MinGW directly.
> The test suite would have to be worked over to provide cygwin
> filesystem test cases. Ugh!
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk