Instead of copying the test executable and the JSON files used by
the tests at install time, define CMake/CTest tests for running
the json_unit executable from any build directory with the project's
source directory as its working directory.
- call enable_testing in the main lists file to allow the definition
of tests
- remove install commands from the test directory's lists file
- define two tests
- json_unit_default for running the default tests by executing
json_unit without any arguments
- json_unit_all for running all the tests by executing json_unit
with the "*" argument
- update the AppVeyor configuration file to use the new testing method
It's sort of gnarly that it's still doing in-tree builds, but I
really, _really_ don't want to get any more friendly with CMake's
Visual Studio generator to work out how to make it stop doing it.
In-tree builds still work, after all, and the goal of this work is
to make out-of-tree builds work as well. Notional horrors like
this will have to wait ;)
The resulting install tree, when tests are enabled, looks like this:
```
.
├── cmake
│ ├── nlohmann_jsonConfig.cmake
│ ├── nlohmann_jsonConfigVersion.cmake
│ └── nlohmann_jsonTargets.cmake
├── include
│ └── nlohmann
│ └── json.hpp
└── test
├── bin
│ └── json_unit
└── data
├── json_nlohmann_tests
│ ├── all_unicode.json
│ └── bom.json
├── json.org
│ ├── 1.json
│ ├── ...
├── json_roundtrip
│ ├── roundtrip01.json
│ ├── roundtrip02.json
│ └── ...
├── json_tests
│ ├── fail10.json
│ └── ...
└── json_testsuite
└── sample.json
```
It has the property that you can invoke the test binary from the
root of the install tree and the tests work correctly (you no
longer depend on the test binary being run inside the source
tree).
If tests are disabled, the entire `test/` subtree is omitted.
Notice how that yields exactly what you want for using this
library in other projects.
I do not believe I need to update travis due to this change, as the
evil Makefile continues to do in-tree builds. I expect I'll find
out soon enough.
This introduces a clear separation between test data and test
binaries. Test data is moved into test/data, and the test binaries
move into test/src. A new CMake script specific to building the
tests is introduced in /test to slightly clean up the toplevel
one.
As well as tidying things up, this makes the next step trivial...
There exist lots of json libraries, and project/target names must
be globally unique. If someone integrated with this library in a
particularly stupid way, using a generic name like "json" might
cause a problem.
I'm not sure that using a variable for target names really helps
with clarity. Unlike paths, target names aren't really something
you change. In a sense, targets are themselves a sort of variable,
so having a variable to name a variable seems just a bit gnarly.
Generate the config files of the package in CMAKE_CURRENT_BINARY_DIR
instead of CMAKE_BINARY_DIR because the later will refer to the main
project's binary directory if the library is included in the project
using the add_subdirectory command.
