I've seen namespace fs = std::filesystem in many examples. On one hand fs is a really short name, which we should avoid. On the other hand, there are very few other meanings of "fs" that I can think of (the other common one being "full screen"). I must say that in this case I personally prefer shorter code, like fs::path or fs::is_directory(file, error), over the longer one, filesystem::path or filesystem::is_directory(file, error). Nothing strong, just a slight preference.

In D12117#314758, @Sybren A. Stüvel (sybren) wrote:

I've seen namespace fs = std::filesystem in many examples. On one hand fs is a really short name, which we should avoid. On the other hand, there are very few other meanings of "fs" that I can think of (the other common one being "full screen"). I must say that in this case I personally prefer shorter code, like fs::path or fs::is_directory(file, error), over the longer one, filesystem::path or filesystem::is_directory(file, error). Nothing strong, just a slight preference.

I have mixed feelings about this. On one side I agree, it's annoying to have to write filesystem all the time. Then again I think, common Julian, it's not that hard of a word to write ;) And it actually makes code less cryptic I think.
We don't need to forbid using fs, but we shouldn't define that in a header at least. So I'd keep the namespace filesystem = ghc::filesystem in BLI_filesystem.hh, but if source files want to use fs, they are free to define that. Personally I'd still prefer not doing that, and using the full filesystem instead though.

In D12117#314827, @Julian Eisel (Severin) wrote:

Then again I think, common Julian, it's not that hard of a word to write ;) And it actually makes code less cryptic I think.

Ok, let's stand with filesystem and let the people who do have strong feelings about fs speak up if they don't agree.

• Add USE_CPP_FILESYSTEM compile option to storage.cc, to keep legacy code around for testing.

To me it doesn't sound temporary enough, and removal of that #define from the code will go back to the current (unwanted) situation.
Maybe USE_LEGACY_FILESYSTEM or USE_OLD_C_FILESYSTEM_LIB? Then we can just remove the entire #define and it'll switch to the future.

• Add blender::bli::filesystem as alias for ghc::filesystem. That should make the ghc -> std transition easier later on since we can just change this alias.

LGTM.

• We could also introduce a way to switch between std::filesystem and ghc::filesystem at compile time.

This could/should be done with a CMake variable.

In D12117#314875, @Sybren A. Stüvel (sybren) wrote:

Maybe USE_LEGACY_FILESYSTEM or USE_OLD_C_FILESYSTEM_LIB? Then we can just remove the entire #define and it'll switch to the future.

+1.
We may have to move this to a higher level, so multiple source files can use it (everything that could be replaced by std::filesystem). So maybe makes sense as a CMake option even. No strong opinion.

• We could also introduce a way to switch between std::filesystem and ghc::filesystem at compile time.

This could/should be done with a CMake variable.

Yeah definitely. Just wondering if we even want to have that option.

In D12117#314880, @Julian Eisel (Severin) wrote:

We may have to move this to a higher level, so multiple source files can use it (everything that could be replaced by std::filesystem). So maybe makes sense as a CMake option even. No strong opinion.

I was thinking the same thing. Could be nice to do some test builds just for the transitional period to see neither code paths are broken.

• We could also introduce a way to switch between std::filesystem and ghc::filesystem at compile time.

This could/should be done with a CMake variable.

Yeah definitely. Just wondering if we even want to have that option.

In that case, let's add it when we know we need it.

I tested this patch on CentOS7, and it also works fine on that platform.