g++ and c++17 filesystem

[Brian Inglis]

On 2020-11-24 07:31, Kristian Ivarsson via Cygwin wrote:
>> On 11/24/2020 4:32 AM, Kristian Ivarsson via Cygwin wrote:
>>
>>> all the std::filesystem implementations I've seen for Windows
>>
>> The implementation on top of Cygwin is not "for Windows", it's "for
>> Cygwin", i.e., "for Posix".  And for Cygwin that's the right thing to do.
>> And that's where we keep talking at cross purposes.

> Maybe it is the right thing to do, but what is your take of why it must be
> so (all the way) ?

Nobody is interested in doing the work to submit and modify patches to get them 
accepted and change it from the way it is.

> I also do understand that it have several advantages in the implementation
> of std::filesystem but it also imply an extra layer of abstraction to the 
> underlaying platform, but to just remove the _CYGWIN_ macro when building it
>  would make std::filesystem to not understand /cygdrive at all (and I guess 
> that would confuse other users;-) so I guess it would require some more 
> sophisticated implementation (or extend the number of exceptions already 
> existing in the underlaying Cygwin-Posix-implementation)
If you only use POSIX compliant Cygwin or UNC (//) paths, all your programs 
built under Cygwin should run successfully under Windows or Wine.
Otherwise if you built under Cygwin, you can overload your directory and file 
path methods so if a path contains : or \\ you call cygwin_conv_path() with 
appropriate flags to fix your path before using it.
Or build with Mingw or MSVC++ and use whatever those allow.

Cygwin is an open source project maintained solely by volunteer contributors in 
their spare time, and its focus is on working around Windows limitations to 
provide a POSIX standard environment and experience, supporting more POSIX 
features as Windows limitations are removed.

Other projects gcc-g++, libstdc++ may have sponsored or employed contributors.
They all have their respective standards focus and are uninterested in 
non-standard-compliant changes and any non-POSIX build changes.
But they build and run just fine under Cygwin.

Feel free to make the appropriate patches to the components and submit the 
patches to the upstream projects.
But be prepared for the upstream projects to reject the patches if they break 
some standard or compliant test case or use case.
Note that it has taken Intel and then MS five years to get FSGSBASE support 
patches accepted in Linux.

If you are unprepared to do the necessary work, you still get a lot more than 
what you paid for. ;^>

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]