CMake update 1/3: basic modernization (preserving all current functionality)

[lubgr]

The existing Windows-only CMake configuration is a great foundation and seems to successfully fill the gap for most Windows users. This PR builds upon that and proposes a modernization of the CMakeLists.txt. CMake has evolved considerably over the last years - while that doesn't make it less of a pain to work with or read the hideous CMakeLists.txt files, there are improvements to be worth taking into account. This PR:

• Simplifies some manual configuration steps by using newer, builtin features.
• Doesn't change any behavior of the Windows build. The Appveyor CI works exactly as before.
• Increases the required CMake version to 3.12. This is still fairly conservative, 3.12 is ~4 years old now.
• Replaces global configuration of preprocessor and compiler flags by target-specific ones. This is what is commonly referred to as "modern CMake": instead of setting e.g. SEXP_USE_INTTYPES globally for every target, we now set it per target and propagate relevant settings by "inheriting" them for other targets through PUBLIC, INTERFACE and PRIVATE specifier. The main benefit lies in better encapsulation and an improved integration into/with other CMake-based projects. I believe the latter is attractive for chibi, as CMake is a fairly dominant choice these days and it would be nice to allow for a seamless integration, e.g. locally with a git submodule) that requires nothing but add_subdirectory(external/chibi-scheme), or using a global installation together with CMake's find_package(chibi-scheme).
• Refactors CMakeLists.txt to allow for a subsequent PR that lifts the platform restriction and makes a CMake build available for Unix-based systems.

There are two follow-up PRs for this (PR 2/3 and PR 3/3). They are in my fork of the repo, as I can't do stacked PRs from fork to origin repo - but when you consider merging this one, I can reconfigure the second one to target this repo and so on.

[ashinn]

I'm not familiar with cmake and don't have access to a Windows machine, but it looks cleaner and doesn't break CI so merging.

Patches for a Unix-based cmake build will be accepted, but the primary build system will always be Make (or theoretically just enough Make to bootstrap a Scheme-based build system). So if you want to continue using cmake you'll have to adapt any changes to the Makefile (which admittedly are gradually becoming fewer).

[lubgr]

Patches for a Unix-based cmake build will be accepted, but the primary build system will always be Make (or theoretically just enough Make to bootstrap a Scheme-based build system). So if you want to continue using cmake you'll have to adapt any changes to the Makefile (which admittedly are gradually becoming fewer).

Yep, I expected that.

[okuoku]

Nice 🎉

I don't have conclusion for add_library(libchibi-scheme ...) or add_library(chibi-scheme ...) issue.. I had used libchibi-scheme because the original (now defunct) MinGW Makefile was generated libchibi-scheme.dll. To support embedding perhaps we should have both add_library(chibi-scheme-shared SHARED ...) and add_library(chibi-scheme-static STATIC ...) and select default library type based on BUILD_SHARED_LIBS.

I think we shouldn't dereference variables inside if command where possible. So BUILD_SHARED_LIBS instead of ${BUILD_SHARED_LIBS} .

[lubgr]

Hey, thanks for having a look!! On the STATIC/SHARED library thing: this should be automatically picked by CMake depending on the the BUILD_SHARED_LIBS option. E.g., with a bare add_library(libchibi-scheme some_source.c ...), it will be either a shared library (default) or a static one with BUILD_SHARED_LIBS=OFF. Not sure if this is already the case in this branch, it certainly will be within the follow-up PR. While this approach doesn't allow building both shared and static library in the same build tree, you can configure two different builds when compiling out-of-source.

I think we shouldn't dereference variables inside if command where possible. So BUILD_SHARED_LIBS instead of ${BUILD_SHARED_LIBS}

Good point. I should fix that in a separate patch.