Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | All our pain comes from this filesystem nonsense and we have to address
> | that anyway for Windows. Once it has been addressed (means store a path
> | by passing it through internal_path and hand it to the outside world
> | after passing this stored path through external_path) then the cost of
> | supporting cygwin is neglibible.
>
> Hmm... have I said boost::filesystem lately?
I refer you to a previous section of the mail you are replying to:
====================================================================
The way that Boost.Filesystem does it is better I think. It
splits the path into two separate entities:
path = root relative-path
where root:
root = root-name root-directory
(So, on unix root-name is empty and on windows it's 'C:' etc)
relative-path = path-element ( '/' path-element)* '/'?
So then all transformations *'\' -> '/') occur to relative-path only.
I think that there are real advantages to moving to the use of
Boost.Filesystem, just not now ;-)
====================================================================
Incidentally, whilst the conceptualisation is great, the implementation of
Boost.Filesystem falls over on cygwin where both Posix and Windows paths
are in use. So we'll still need
namespace fs = boost::filesystem;
fs::path const internal_path(std::string const & path_str)
{
#if defined (__CYGWIN__) || defined(__CYGWIN32__)
if (fs::windows_name(path_str))
return fs::path(subst(path_str, '\\', '/'));
return fs::path(path_str);
#elif defined (_WIN32)
if (fs::windows_name(path_str))
return fs::path(path_str);
return fs::path();
#elif defined (__EMX__)
//We'll have to write our own code here???
#else // POSIX
return fs::path(path_str, fs::no_check);
#endif
}
Similarly, we'll still need external_path().
No, Jean-Marc. This does not mean we should drop support for cygwin.
--
Angus
