Sv: g++ and c++17 filesystem

[<sten.kristian.ivarsson@gmail.com>]

> >>> 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 totally understand that it might be a big task, but (as I said) I cannot
understand the reluctancy of even wanting the feature (as far as I
experience;-)

One might ask what the use case for Cygwin is ? We don't need to go into
this rabbit hole though ;-)

See more below


> > 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

Thanx for the tip, maybe I'll look into that, but I guess we need to have
our own distro of Cygwin then (or could this be set for changing the
behaviour for own built applications) ?

> 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.

I'm aware of that and I'm asking these question because I'm working on an
open source project as well (so this is pure voluntarily as well:-),
targeting *nix-system, but we have a task to make it working on Windows as
well and we were hoping to not have the need to add platform specific code
(to "clean up" input paths that are perfectly normal for users using
Windows)

> 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. 

Yeah, I discovered that the _CYGWIN_ defines actually were in the (real)
libstdc++-distro, so I totally understand that

> 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.

Thanx for the more concrete tips and maybe I'll do that some day

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

Ha haa, you're probably right, but I can tap myself on the shoulder and feel
that I made the world a bit better

I'm totally used to have pull-requests and enhancement-issues to open source
projects laying around for ages before approved

Thanx Brian

Best regards,
Kristian

> --
> 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.]
> --
> Problem reports:      https://cygwin.com/problems.html
> FAQ:                  https://cygwin.com/faq/
> Documentation:        https://cygwin.com/docs.html
> Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple