Use std::filesystem instead of pre-C++17 alternatives#3
Open
PhoenixBound wants to merge 3 commits into
Open
Conversation
It's been 9 years. All the compilers support C++17 well now, 100%. Visual Studio 2022 still supports Windows 7, so that part's fine. gcc 8 and the associated libstdc++ version were released in May 2018; Debian oldoldstable (bullseye as of writing) has gcc 10, and my understanding is that Debian is normally considered to be pretty late to get new versions of things. I'm not expecting this to get merged right away, but it'd nice to delete code, once that does become realistic.
MSVC has a loud deprecation "warning" (error) for things that are deprecated in C++17, namely the Windows codecvt junk. Ideally this would be fixed as part of u8string-ifying and fs::path-ing everything in the compiler, but that's a big change and would probably screw up existing UTF-8 and Japanese support others are working on... so take the easy way out for now. Also removes the weird restriction that only Mac and Linux can have compiler flags (what about the BSDs and other Unix-like OSes?). This platform logic is probably a bit broken in some edge cases. setuptools' logic for choosing a C compiler is possible to introspect, apparently (https://stackoverflow.com/a/32192172), but I don't think there's a direct way to check it. All I could find is the logic for choosing a "default" compiler, and that's to use MSVC on Windows in all cases except when MinGW/MSys or Cygwin is detected. I thought I remembered Python docs saying "use a compiler with the same ABI as what Python was compiled with," which is why I reached for platform.python_compiler() here...
As far as I can tell, all of these interfaces are documented parts of either setuptools or distutils. The linked GitHub issues currently offer no advice for avoiding "ccompiler" APIs, and the linked documentation recommends inheritance from the build_ext command class to extend things. The setuptools pip package is supposed to provide the 'distutils' import package, so this should work even on Python versions where distutils has been removed, in theory.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
One possible fix for compile errors on Visual Studio 2026, after it removed the "experimental" filesystem header. After testing the initial version on my laptop (running Debian), I tweaked it further on Windows to bring MSVC in line with it.
It's been 9 years. All the compilers support C++17 and
std::filesystemwell now:I haven't asked anyone what versions of macOS and what Linux distro versions we need to support/what versions of Linux people in the PK Hack community use. An alternate version of this PR that doesn't affect Unix-like operating systems is provided in #4, but it'd be nice to delete the vendored filesystem code, if that is realistic/once that does become realistic.