g++ and c++17 filesystem
Wed Nov 25 00:23:31 GMT 2020
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.]
More information about the Cygwin