Commit 73cc5089 (Using target_compile_features to specify C++ 11
standard) bumped the required cmake version, from 3.0 to 3.8, so
as to get the definition of target_compile_features().
However, target_compile_features() was introduced in cmake-3.1:
https://cmake.org/cmake/help/v3.1/command/target_compile_features.html
And using cmake-3.1 is indeed sufficient to properly build.
As such, relax the minimum required version down to cmake-3.1,
so we can build on oldish, entreprise-grade distributions that
only have cmake-3.1 (or at least, don't have up to cmake-3.8).
Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
When adding this library as embedded library with private
"target link", e.g. only used inside private source files, the
library does not need to be installed when the main project gets
installed.
This adds an additional option `JSON_Install` similar to the
test-build control switch in order to skip installing headers and
CMake config files if requested.
Avoids using
```cmake
add_subdirectory(path/to/nlohmann_json EXCLUDE_FROM_ALL)
```
which has further side-effects:
https://cmake.org/cmake/help/v3.0/command/add_subdirectory.html
CMake convention is to use a project namespace, i.e. Foo::, for imported
targets. When multiple targets are imported from a project, this looks
like Foo::Bar1 Foo::Bar2, etc. This adds the nlohmann_json:: namespace to
the exported target names.
This also allows the generated project config files to be used from the
build directory instead of just the install directory.
- 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.
