Lars Gullik Bjønnes wrote:
> | L>>> #define BOOST_POSIX 1
>>>>
>>> | Yes, this works.
>>>
>>> Ok.
>>>
>>> Then we have to decide on the best way to handle this.
>>>
>>> If we just make BOOST_POSIX be set for cygwin, then it works for you.
>>> But for the next guy using cygwin it will break.
>>
> | No, I don't think so. All our file names currently go through
> | "internal_path" which sort-of-posixifies them. I've no idea why things
> | appear to be working on a true Windows platform, but I think you've
> | just been lucky.
>
> Ok, then we are back to scratch.
>
> What you are saying is that using filesystem calls from windows.h is
> perfectly ok when writing appications for cygwin?
I think that we two need to sit down with beers, because all this
long-distance typing just leads to mutual confusion. I'm not trying to
have a go. I'm just trying to help see through the mess.
At the moment, we have "a bit of this and a bit of that".
We have the "old" way, in which all file names are "sort-of-posixified" by
os::internal_path before the rest of LyX sees them. Similarly, we
"sort-of-go-native" when we pass these names through os::external_path on
the way back to the outside world.
We have the "new", Boost.Filesystem way which handles all operations on
these file names. You've got lucky because you're effectively constructing
these fs::paths using "generic Boost.Filesystem path syntax". Ie, you're
always passing "sort-of-posixified" file names to the fs::path
constructor, irrespective of the OS.
I guess that the problems are arising because of this "half one way, half
the other". Unfortunately, we can't get rid of os::internal_path and use
the obvious and explicit
fs::path(name, fs::native);
to constuct these paths because, as we've just found out, Boost.Filesystem
expects a particular OS to use either Windows or Posix-style paths and
Cygwin can use BOTH. Boost.Filesystem cannot cope with that.
That's my yake on the situation. Does it make sense to you too?
--
Angus
