std::filesystem header detected on macOS Mojave but not supported

[jwillikers]

The check for the std::filesystem header is not robust enough for older versions of macOS. Versions of macOS up to Mojave may have the std::filesystem header while not having support for std::filesystem implemented in Apple's version of the standard C++ library. This leads to a compiler error. In particular, I am using MacPorts Clang 11 on macOS Mojave and version 3.6.0 of toml11.

[ToruNiina]

Wait, if I'm not mistaken, it lacks the implementation of filesystem related function in the dynamic library and, at the same time, both __cpp_lib_filesystem and __has_include(<filesystem>) return true?

Hmm, the only idea I have is to detect __APPLE__ and the clang version. But I don't know exactly which version leads the problem. Do you know whether this problem has been resolved with appleclang 12? I found that on travis CI, I only tested even older one. I need to have CIs for macos.

[jwillikers]

I think its related to the deployment target, i.e. the target version of macOS which ends up causing the error even though the defines are set. I found this which describes the problem a bit more and links to a workaround here.

[ToruNiina]

I'm verry sorry for the late reply. I have decided to add a macro to disable <filesystem> related features because of the following reasons.

• The problem is limited in a special case and the required solution is also complicated (it depends on the implementation or build systems.)
• I don't have an older macos machine so I couldn't do enough experiment on the solution and its capability

I'm sorry for the possibly-incomplete solution, but I think it is better to add a way to avoid the problem compared to nothing, so I added TOML11_DISABLE_STD_FILESYSTEM to disable the feature.

[monkeydom]

Ah nice. That sounds good to me too. Wanted to investigate if I could lower the macOS deployment target again, especially because in my use case the actual file IO is done on the other side of the library fence.