In e8b6b7ad, we relaxed the cmake version check down to 3.1, the first
version to expose target_compile_features().
However, an error while testing that change improperly concluded that
the change was OK. While target_compile_features() was indeed intriduced
in cmake 3.1, the actual feature we use it to test, cxx_std_11, was
really introduced only with cmake-3.8, which explained the actual
version that was requested before e8b6b7ad.
As Patrick noted, however, we can still convince cmake-3.1 to test
for C++11, by testing for an actual feature introduced in C++11, like
testing for cxx_range_for, which will instruct cmake to set the
appropriate C++11 options for the current compiler, which for gcc would
be adding -std=gnu++11.
Reported-by: Patrick Boettcher <patrick.boettcher@posteo.de>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
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>
Fix issue #1340.
The eofbit is set manually since we don't go through the
stream interface. We could maybe use the stream interface
instead, but there are some assumptions regarding which
exception go through, so this seems to be the most prudent
approach for now.
is_compatible_* traits were used in from_json, but it made no sense
whatsoever.
It used to work because of non-SFINAE correctness + json_ref
unconstrained variadic template constructor.
SFINAE checks are becoming quite complex, we need a specification of
some sort describing:
* which concepts the library uses
* how the conversion to/from json works in detail
Having such a specification would really help simplifying the current
code (as well as having meaningful checks).
Fixes!1299
