- updated documentation wrt. new repository layout
- temporarily switched off Homebrew --HEAD building (can only be switched on after release)
- set copyright date to 2018
* Rename 'develop' folder to 'include/nlohmann'
* Rename 'src' folder to 'single_include/nlohmann'
* Use <nlohmann/*> headers in sources and tests
* Change amalgamate config file
The tool used before created a lot of duplicates inside the generated amalgamation. The new tool is a single Python file which seems to do the same job.
The rewrite uses more cmake build-in automatisms and build-in generates
variables to allow better generic reuse.
* cmake files are installed to
``` <install_prefix>/lib/cmake/nlohmann_json/ ``` for best support on
most systems
* include path is set to ``` include ``` for usage as ``` #include
<nlohmann/json.hpp> ```
- Add prefix header
- Include catch.hpp
- Include json.hpp
- Replace private with public for all json_unit files
- Move `unit.cpp` to an object library
- cotire issue: strip whitespace from CMAKE_INCLUDE_SYSTEM_FLAG_CXX
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
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.
- define the project's version in the cmake listfile
- create a config and config version file for the cmake package
- install the json.hpp file and the package's targets, config and
config version files
Define the library as an interface imported library so other targets
can use the library as a dependency and use the interface properties
of the library.
