std::filesystem unavailable on macOS lower deployment targets

[kevin--]

Steps to Reproduce

Building with C++17, and nlohmann v3.10.4, targeting macOS Deployment Target of 10.14

/Users/distiller/project/app/lib/nlohmann/single_include/nlohmann/json.hpp:4384:57: error: 'path' is unavailable: introduced in macOS 10.15
void from_json(const BasicJsonType& j, std::filesystem::path& p)
                                                        ^

etc,

Basically since C++ library features are implemented in macOS and not via a redistributable system, Xcode refuses to compile if it knows a feature will be unavailable. For example, std::variant does not work until 10.12

It is a product requirement for our minimum deployment target to be set at 10.14, but we are building with C++17 regardless and just need to avoid using features we can't rely on being present at runtime.

What is the expected behavior?

Use of std::filesystem is opt-in rather than automatically used if C++17 is available.

And what is the actual behavior instead?

I guess we would have to lower our compile standard to C++14, however since nlohmann is header only we can't lower our standard for the entire project.

Which compiler and operating system are you using?

MacOS 10.15.7
Xcode 12.4

Apple clang version 12.0.0 (clang-1200.0.32.29)
Target: x86_64-apple-darwin19.6.0

Which version of the library did you use?

• latest release version 3.10.4
• other release - please state the version: ___
• the develop branch

If you experience a compilation error: can you compile and run the unit tests?

• yes
• no - please copy/paste the error message below

[kevin--]

Using

target_compile_definitions( nlohmann_json INTERFACE -DJSON_HAS_CPP_14 )

as a work around for now

[nlohmann]

Duplicate of #3090. You can try 3.10.3 until the issue is fixed.

[kevin--]

I would say that it is not an exact duplicate @nlohmann because if we change the macOS Deployment Target, the same toolchain can compile successfully (no use of experimental headers etc)

You may not be able to do a simple toolchain check to determine the behavior in this case.

[nlohmann]

How would such a check look like?

[kevin--]

in CMake, we use the variable CMAKE_OSX_DEPLOYMENT_TARGET ( see https://cmake.org/cmake/help/latest/variable/CMAKE_OSX_DEPLOYMENT_TARGET.html )

For example in a top level CMakeLists.txt for macOS we might do something like this:

set( CMAKE_OSX_DEPLOYMENT_TARGET "10.12" )

I think you could query this at configure time to make some determination... pseudo code here:

if( CMAKE_OSX_DEPLOYMENT_TARGET GREATER_EQUAL "10.15" )
    target_compile_definitions(nlohmann_json INTERFACE "-DRUNTIME_HAS_FILESYSTEM=1" )
endif()

notably the meaning of CMAKE_OSX_DEPLOYMENT_TARGET changes if cross compiling for iOS (becomes an IOS version) so you might need to add additional checks if( AppleClang && IOS )... Sorry I don't have more details on iOS's runtime support of filesystem

[nlohmann]

We already do this in #3101 which should fix this issue:

        // no filesystem support before iOS 13
         #if defined(__IPHONE_OS_VERSION_MIN_REQUIRED) && __IPHONE_OS_VERSION_MIN_REQUIRED < 130000
             #undef JSON_HAS_FILESYSTEM
             #undef JSON_HAS_EXPERIMENTAL_FILESYSTEM
         #endif

         // no filesystem support before macOS Catalina
         #if defined(__MAC_OS_X_VERSION_MIN_REQUIRED) && __MAC_OS_X_VERSION_MIN_REQUIRED < 101500
             #undef JSON_HAS_FILESYSTEM
             #undef JSON_HAS_EXPERIMENTAL_FILESYSTEM
         #endif
     #endif

Unfortunately, there is still a failing CI with Clang 9 which we need to fix before this can be merged. However, you can already try if branch issue3090 works for you.

[kevin--]

ok that's a much better solution than I had proposed. I will try it out and confirm. Thanks

[nlohmann]

ok that's a much better solution than I had proposed. I will try it out and confirm. Thanks

That would be awesome.