Using full paths is more versatile. The current solution
breaks when specifying an absolute path for CMAKE_INSTALL_INCLUDEDIR
which is an otherwise supported option by CMake's GNUInstallDirs.
CMake does not support Autoconf-style ${prefix}-pseudo variables,
hence trying to emulate the behaviour gains us nothing and breaks
providing absolute paths to CMAKE_INSTALL_LIBDIR.
Plus some other build-related changes. I don't think there is anything
functionally different from 1.7.7, or even any binary incompatibilities, but
the cmake change is significant.
* The GNUInstallDirs module is more idiomatic and supported by
Kitware upstream, whereas the current directories are not
standardised across CMake-using packages. Using CMake native
mechanisms is better than reinventing the wheel, as it makes
using the build system more uniform across the ecosystem
* Use CMAKE_CXX_STANDARD to force C++11
* Require CMake 3.1.0 at a minimum
* Fixed lower/UPPERcase format for function/macro calls
* Fixed indents by replacing tabs with 4 spaces
Removed a static variable used to contain the current recursion depth of Reader::readValue(). The number of elements in an internal container Reader::nodes_ is used instead. It is correct because any recursive call of Reader::readValue() is executed with adjacent nodes_.push() and nodes_.pop() calls.
Added the option to change the allowed recursion depth at compile time by defining a macro JSONCPP_STACK_LIMIT as the required integer value.
Rename variable empty to emptyString in Value constructor to avoid shadowing of Value::empty().
GCC 4.8 produces the warning about this:
lib_json/json_value.cpp: In constructor ‘Json::Value::Value(Json::ValueType)’:
lib_json/json_value.cpp:346:27: warning: declaration of ‘empty’ shadows a member of 'this' [-Wshadow]
Otherwise failures like these one can happen during the configure phase
of other applications that use jsoncpp, like upmpdcli for instance:
checking jsoncpp/json/json.h usability... yes
checking jsoncpp/json/json.h presence... yes
checking for jsoncpp/json/json.h... yes
configure: error: libjsoncpp not found.
And this is the actual problem that you can see in config.log:
configure:5233: checking for jsoncpp/json/json.h
configure:5233: result: yes
configure:5259: /usr/bin/mipsel-linux-g++ -o conftest conftest.cpp
-lmicrohttpd -lmpdclient -lpthread -ljsoncpp >&5
In file included from /usr/include/jsoncpp/json/autolink.h:9:0,
from /usr/include/jsoncpp/json/json.h:9,
from conftest.cpp:26:
/usr/include/jsoncpp/json/config.h:155:9: error: 'int64_t' does not name
a type
typedef int64_t Int64;
^
/usr/include/jsoncpp/json/config.h:156:9: error: 'uint64_t' does not
name a type
typedef uint64_t UInt64;
^
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
