Make use of std::filesystem optional via e.g. cmake

[timosachsenberg]

I think it could make sense to make the use of filesystem functions optional.
In our case we don't use them, but it causes a few build errors on different systems.
E.g., we can't support older macOS clang versions and also the gcc on Ubuntu 18.04 failed to
properly detect whether we have the experimental/filesystem or filesystem header.

BTW, for us, we got it working by adding these two small lines as a patch to Database.h
https://github.com/OpenMS/OpenMS/pull/6498/files

but maybe the use of filesystem is something that could also be configured through cmake?

[piperoc]

Thanks for the fix, got me out of a jam: I need to build for Ubuntu 18.04 and 20..04 so your fix helped a ton.
I agree that a CMake option might be cleaner.

[UnixY2K]

I think it could be possible to add a option that adds a preprocesor definition that disables it, it should be something like this:

option(SQLITECPP_DISABLE_STD_FILESYSTEM "Disable the use of std::filesystem in SQLiteCpp." OFF)
if (SQLITECPP_DISABLE_STD_FILESYSTEM)
    message (STATUS "Disabling std::filesystem support")
    add_definitions(-DSQLITECPP_DISABLE_STD_FILESYSTEM)
endif (SQLITECPP_DISABLE_STD_FILESYSTEM)

and then under database.h after SQLITECPP_HAVE_STD_FILESYSTEM and SQLITECPP_HAVE_STD_EXPERIMENTAL_FILESYSTEM

#ifdef SQLITECPP_DISABLE_STD_FILESYSTEM
    #undef SQLITECPP_HAVE_STD_FILESYSTEM
    #undef SQLITECPP_HAVE_STD_EXPERIMENTAL_FILESYSTEM
#endif

so we can manually disable the support and detection of std::filesystem

another option is to use the __has_include macro of c++17 like the following after the other checks for std::filesystem

#ifdef __has_include
    #if __has_include(<filesystem>)
        #define SQLITECPP_HAVE_STD_FILESYSTEM
    #else
        #undef SQLITECPP_HAVE_STD_FILESYSTEM
    #endif
    #if __has_include(<experimental/filesystem>)
        #define SQLITECPP_HAVE_EXPERIMENTAL_FILESYSTEM
    #else
        #undef SQLITECPP_HAVE_EXPERIMENTAL_FILESYSTEM
    #endif
#endif

on the meson project this could be done the same way by using an option or checking at setup if a test program compiles via

std_filesystem_support_code = '''
    #ifdef __has_include
        #if __has_include(<filesystem>)
            #include <filesystem>
        #elif __has_include(<experimental/filesystem>)
            #include <experimental/filesystem>
        #else
            #error "No std::filesystem support"
        #endif
    #endif
'''

std_filesystem_support = cxx.compiles(std_filesystem_support_code, name : 'support for std::filesystem')

if get_option('SQLITECPP_DISABLE_STD_FILESYSTEM') or not std_filesystem_support
    sqlitecpp_cxx_flags += ['-DSQLITECPP_DISABLE_STD_FILESYSTEM']
endif

if this seems a good option I could send the PR, just let me know what do you think

[eli-schwartz]

on the meson project this could be done the same way by using an option or checking at setup if a test program compiles via

You don't need support code for this. cxx.has_header('filesystem') does this for you already (uses __has_include() even) and also is faster than .compiles() because it only runs the preprocessor.

However, doing this in the source code at build time is much faster since you're running the compiler at that time anyway. At least if you're positive your compiler implements C++17 __has_include().

[UnixY2K]

However, doing this in the source code at build time is much faster since you're running the compiler at that time anyway. At least if you're positive your compiler implements C++17 __has_include().

Right, so on meson we would not need to do the additional check as it is already checked on the source code, we can remove the check in the meson file.

most compilers support __has_include we so we could just add an else in the macro check if that option is not supported, and if for some reason there is an edge case we can check it out on meson.

Honestly I don´t know if there is a edge case for a C++17 compiler that supports std::filesystem but not __has_include so unless anyone open an issue about it it should not be an real issue

[UnixY2K]

this should be fixed in #388, feel free to test it

[UnixY2K]

added fixes on #393

[UnixY2K]

released support in 3.3.0

[SRombauts]

Thanks @ninjaoflight