Re: g++ and c++17 filesystem
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.] -- 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
Re: g++ and c++17 filesystem
On 2020-11-18 17:08, Doug Henderson via Cygwin wrote: On Wed, 18 Nov 2020 at 13:50, Kristian Ivarsson wrote: The only purpose CYGWIN have is to make/build posix-applications runnable on Windows and applications usually have user defined input, such as paths etc, and on Windows that input is usually Windows-native-paths unless you educate operators/users to enter paths with /cygdrive/... I use CYGWIN to work around a stupid design decision made by a small time OS developer more than 40 years ago, and inherited by an OS that did not even have directories in its first release. Actually, most of those design decisions were made in the 1950s-1960s by scientific then mainframe OS designers in multiprocessing then multiuser environments, and the short sighted decisions were made to get things working quickly by people without much design or systems background (BGIII^Wcough!) in some of the smaller minicomputer then microcomputer adaptations, which were often frankly PoS hacks, and triumphs of salesmanship over competency. ;^> -- 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
Re: g++ and c++17 filesystem
On Wed, 18 Nov 2020 at 13:50, Kristian Ivarsson via Cygwin wrote: > > > The only purpose CYGWIN have is to make/build posix-applications runnable on > Windows and applications usually have user defined input, such as paths etc, > and on Windows that input is usually Windows-native-paths unless you educate > operators/users to enter paths with /cygdrive/... I use CYGWIN to work around a stupid design decision made by a small time OS developer more than 40 years ago, and inherited by an OS that did not even have directories in its first release. Doug -- Doug Henderson, Calgary, Alberta, Canada - from gmail.com -- 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
Re: g++ and c++17 filesystem
On 11/18/2020 4:18 PM, Kristian Ivarsson wrote: I would agree that if you want an executable that acts and feels more like a Windows native application, then mingw is probably what you want. Cygwin is if you want something that acts and feels more like a Posix thing ... which means it will be oriented to Posix style paths. To be able to use mingw all the code have to be ported to use Windows native mechanisms and then we might just use MSVC instead We don’t want (either) Windows-style-paths or Posix-style-paths, we want A path and expect it to work equally regardless of what platform is used in regards to std::filesystem As far as I see, very few applications do form their own - and/or have hard-coded absolute paths and instead they are usually input data (through UI, configuration, OS, environment or such) IN this context, I would say "Which std::filesystem? The Cygwin Posix-like one or the mingw Windows-like one?" If you want uniformity, I'd go with Cygwin; it you want platform-like behavior, then mingw. Best wishes - EM -- 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
Re: g++ and c++17 filesystem
On 11/18/2020 3:46 PM, Kristian Ivarsson via Cygwin wrote: Is there any other use cases for CYGWIN than to build applications running in Windows ? Do people use CYGWIN (shell) to operate or monitor their applications ? For all other use cases than the development (the shell) I cannot see why CYGWIN would favour posix-paths over native path’s, but maybe I’m wrong ? To write software that can be compiled and run under Windows, Linux and MacOS. -- 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
Re: g++ and c++17 filesystem
> I would agree that if you want an executable that acts and feels more like a > Windows native application, then mingw is probably what you want. Cygwin is > if you want something that acts and feels more like a Posix thing ... which > means it will be oriented to Posix style paths. To be able to use mingw all the code have to be ported to use Windows native mechanisms and then we might just use MSVC instead We don’t want (either) Windows-style-paths or Posix-style-paths, we want A path and expect it to work equally regardless of what platform is used in regards to std::filesystem As far as I see, very few applications do form their own - and/or have hard-coded absolute paths and instead they are usually input data (through UI, configuration, OS, environment or such) > EM -- 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
Re: g++ and c++17 filesystem
I would agree that if you want an executable that acts and feels more like a Windows native application, then mingw is probably what you want. Cygwin is if you want something that acts and feels more like a Posix thing ... which means it will be oriented to Posix style paths. EM -- 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
Re: g++ and c++17 filesystem
> 18 nov. 2020 kl. 17:26 skrev René Berber via Cygwin : > > On 11/18/2020 3:00 AM, Kristian Ivarsson via Cygwin wrote: > On 11/17/2020 9:15 AM, Kristian Ivarsson via Cygwin wrote: >>> The filesystem-library as a part of C++17 seems to have some defects and flaws in the cygwin-package and pretty much every lexical- and canonical operation works in mysterious ways (or not at all) >>> [snip] >>> >>> https://cygwin.com/cygwin-ug-net/using.html#pathnames-win32 >> So by this you're saying that cygwin-applications cannot handle the >> filesystem it is supposed to handle ? > > I'm not saying anything, I'm pointing to the relevant documentation. > >> How come std::filesystem first say "It's a valid file" followed by "It's not >> a valid file" ? Is that part of the "circumvention" ? > > The documentation states that using Windows notation is not supported and may > result in unexpected results (i.e. sometimes work, sometimes doesn't). [snip] > Cygwin handles the file system with no problem, but using Posix-like > notation, not Windows-like. End of story. Well, the sole reason behind this question was to either find an existing solution to this issue or perhaps invoke some work to improveme CYGWIN, because no developer, operator or user likes undefined behaviour and I think that we all can agree to that it would be kind of nifty if this worked as expected and thus I don’t consider this to be the end of the story I’m thankful that you pointed out the documentation (that I already have read some while ago) and by “you” I didn’t mean you in person but more directed to the “community” The only purpose CYGWIN have is to make/build posix-applications runnable on Windows and applications usually have user defined input, such as paths etc, and on Windows that input is usually Windows-native-paths unless you educate operators/users to enter paths with /cygdrive/... ... or you have to add code to kind of transform possible Windows-paths to Posix-paths (perhaps back and forth), well then you’re adding non-posix-logic (non-cross-platform-logic) to your application and that makes it one reason less to use CYGWIN Is there any other use cases for CYGWIN than to build applications running in Windows ? Do people use CYGWIN (shell) to operate or monitor their applications ? For all other use cases than the development (the shell) I cannot see why CYGWIN would favour posix-paths over native path’s, but maybe I’m wrong ? So, a library can always go from undefined to defined without breaking changes, so does anyone know what the effort could be to fix this, i.e. make it work transparently/agnostic ? As stated earlier, it seems like using mingw g++/libstdc++ (from the cygwin-package-manager) it seems like it works better, but then you can’t mix with other posix/cygwin mechanism (that uses cygstdc++) without breaking ODR (and probably some memory models etc as well) so maybe someone do have some insightful info about this ? How “special” is cygstdc++ (compared to mingw:s libstdc++) ? Could this be fixable in that library (cygstdc++) ? Best regards, Kristian > -- > R.Berber > -- > 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 -- 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
Re: g++ and c++17 filesystem
On 11/17/2020 9:15 AM, Kristian Ivarsson via Cygwin wrote: The filesystem-library as a part of C++17 seems to have some defects and flaws in the cygwin-package and pretty much every lexical- and canonical operation works in mysterious ways (or not at all) [snip] https://cygwin.com/cygwin-ug-net/using.html#pathnames-win32 -- R.Berber -- 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
