Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-12-01 11:39:42


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,
>so:
>
> $ 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 filesystem".

Just using defined(__CYGWIN__) doesn't work, since it gets defined for all
gcc compiles (at least if cygwin is installed on the machine).

The test suite would have to be worked over to provide cygwin filesystem
test cases. Ugh!

--Beman


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk