Reorganize CMake code and add feature summary

[falbrechtskirchinger]

This PR cleans up the CMake code a bit in preparation for adding static library support.

• Use "section style" from test.cmake in the main list file and have fewer sections with a single line of code. Alternatively, we could use the old section style, but I find the current choice visually clearer and less awkward for single-line sections.
• Add a custom feature summary. CMake's built-in feature summary doesn't produce nice output with our choice of options.
• Move option and configuration handling into a separate file.
• Move system information into a separate file and use CMake's built-in variables and tools instead of manually calling uname, etc.
• Merge download_test_data.cmake into test.cmake and make JSON_TestDataDirectory configurable via environment variable.
• Rename ci.cmake/test.cmake to json_*.cmake.
• Some changes are loosely inspired by range-v3.

I've held back a few changes that might break stuff and need careful review for a follow-up PR. There're some cosmetic changes affecting the same code that could still be done in this PR, though.

Notes for the follow-up PR:

• CMAKE_MEMORYCHECK_COMMAND is not an official CMake variable? (If so, rename.)

[coveralls]

Coverage remained the same at 100.0% when pulling 0c1454c on falbrechtskirchinger:cmake into 17d9eac on nlohmann:develop.

[falbrechtskirchinger]

This style ("[nohmann_json]: ") is used by range-v3. Makes it more clear where the output is coming from when the project is used via add_subdirectory(), for example.

[falbrechtskirchinger]

Looks good to me.

[falbrechtskirchinger]

I added NEGATE to the wrong call of json_feature(). Fixed.

[nlohmann]

I have not yet checked whether the new structure feels simpler to me, but only checked the CMake output in a terminal.

Some observations:

1. I think it is a bit too noisy in case the library is just integrated into a bigger project:

   -- [nohmann_json]: CMake 3.24.2
   -- [nohmann_json]: Host system: Darwin-21.5.0
   -- [nohmann_json]: C++ compiler: Apple clang version 14.0.0 (clang-1400.0.29.102)
   -- [nohmann_json]: Feature summary:
      Build tests? NO
   
      Diagnostics enabled? NO
      Default integer enum serialization enabled? YES
      Define user-defined string literals globally? YES
      Implicit conversions enabled? YES
      Legacy discarded value comparison enabled? NO
   
      Use the multi-header code? YES
      Include directory: /Users/niels/Code/repositories/json/include/
      Include as system headers? NO
   

   To my taste, this is too much output.

2. When using ANSI escapes, one should always make sure if the terminal is supporting them in the first place. I was using ccmake and got this output:

   

3. I had my reasons to call tools like uname to get better information on the operating system, etc.

   This is what I got on my system before:

   -- Operating system: Darwin-21.5.0; ProductName:	macOS; ProductVersion:	12.4; BuildVersion:	21F79; Darwin stewie.fritz.box 21.5.0 Darwin Kernel Version 21.5.0: Tue Apr 26 21:08:37 PDT 2022; root:xnu-8020.121.3~4/RELEASE_ARM64_T6000 arm64
   -- Compiler: Apple clang version 14.0.0 (clang-1400.0.29.102); Target: arm64-apple-darwin21.5.0; Thread model: posix; InstalledDir: /Library/Developer/CommandLineTools/usr/bin
   

   This is what I get with this PR:

   -- [nohmann_json]: Host system: Darwin-21.5.0
   -- [nohmann_json]: C++ compiler: Apple clang version 14.0.0 (clang-1400.0.29.102)
   

   To me, "macOS 12.4" is easier to understand than just "Darwin-21.5.0".

[falbrechtskirchinger]

1. I think it is a bit too noisy in case the library is just integrated into a bigger project:

What do you suggest? Most features produced some output and it appears that for new features this was simply forgotten. The difference is, that the feature summary will always output something instead of only when a feature is "active" (enabled or disabled depending on the feature). I'd argue that this predictable structure is easier to read and obviates any need to guess whether a feature is enabled or not.
Any moderately complex project will print a feature summary at the end of the configuration phase and that's why I've come to expect it. Also, for bigger projects that integrate this library, the amount of log output should proportionally be minuscule.

In any case, we could disable the output in specific situations, for example:

• JSON_MAIN_PROJECT == FALSE
• CMAKE_LOG_LEVEL != VERBOSE|DEBUG|TRACE

To my taste, this is too much output.

In this instance, I disagree, but I feel that way about the current OS info output (see below). ;-)

2. When using ANSI escapes, one should always make sure if the terminal is supporting them in the first place. I was using ccmake and got this output:

True. Unfortunately, this is probably impossible to do in CMake and I relied on most terminals supporting ANSI codes these days (even Windows supports ANSI now, I learned today) and accepted garbled output to text files. It could be done using cmake -E cmake_echo_color, but I'd have to break up writing of lines into more than one step and lines are already separated by output to the other channel (stdout or stderr). This is especially visible in CI and I intend to fix it by outputting the whole feature summary in one go.

Guess I'll remove the escape sequences. Too bad we can't have nice things. :-(

3. I had my reasons to call tools like uname to get better information on the operating system, etc.
   (...)
   To me, "macOS 12.4" is easier to understand than just "Darwin-21.5.0".

I agree wholeheartedly. I noticed it in CI and then forgot to put in the fix. Here's what the output was supposed to look like:

[nohmann_json]: Host system: macOS 11.7 20G817 x86_64 (Darwin-20.6.0)
[nohmann_json]: Host system: Debian GNU/Linux 11 (bullseye) x86_64 (Linux-5.15.0-1020-azure)
[nohmann_json]: Host system: Windows DataCenter Server (Build 17763) AMD64 (Windows-10.0.20348)

(On Linux we see some inaccuracies because of virtualization, but that is independent of the tools used. It would be easy to add information about the virtualized environment on most modern distributions using systemd-detect-virt, but I don't think that's needed. Just something to be aware of.)

Is that acceptable?

In this instance, I find the old output way too verbose and noisy. When is the added information actually helpful and do you not have to ask people to provide the log output anyway, in which case you could also ask for specific command output?

Note that the new output will also include a Target system: line if code is being cross-compiled, which should be useful given the unique issues on embedded platforms.

[falbrechtskirchinger]

I've made some modification to the json_feature() function:

• Output is now padded instead of bolding the value via ANSI escapes. (json_feature(KEY_VALUE) overload)
• Output can be conditionally enabled via the SWITCH <conditonal_args>... parameter. Example:

  json_feature(KEY_VALUE "Feature enabled?" JSON_Feature SWITCH ${JSON_MAIN_PROJECT})`

  Output will only appear if ${JSON_MAIN_PROJECT} evaluates to TRUE.
• Newlines will be collapsed or removed to avoid redundant newlines surrounding empty sections.

Using these tools, the output can be adjusted as desired.