If jsoncpp is a subproject (like a git submodule), setting the
global cmake variables affect the entire project (changes the
structure of the output folders) and these changes prevent it.
CMake provides helpers to generate config file. Generated config file has usefull macro check_required_components() to set necessary variables like PackageName_FOUND if requirements has been satisfied. An absence of dedicated config file confuses user project as necessary variables are not set.
* ENH: Prevent cmake in source builds
Building directly inside the root of the source tree
can cause problems where the build intermediate files
overwrite or conflict with the intended source code
files.
This modification identifies this problem and
issues failure messages and suggestions to over
come the problem with more robust build suggestion.
Co-authored-by: Jordan Bayles <jophba@chromium.org>
* BUILD_TYPE corresponds to Release/Debug
but LIB_TYPE corresponds to shared/static.
* Add support to build shared, static and object lib at the same time.
Commit aebc7fa added version checks for CMake compatibility. In reality,
only the add_compile_definitions need the check - add_compile_options
itself has been supported since 3.0. Tested and confirmed built
successfully with CMake 3.8.0.
Since CMake has subdirectory variable scope, unilaterally set the
CMAKE_CXX_STANDARD variable to use C++11. This covers cases with the
library being included externally, both in cases of only C++98 being
specified, as well as later versions being specified (since the
CXX_STANDARD itself isn't a library dependency, only the PUBLIC
target_compile_features on jsoncpp_lib). The previous direct check for
C++98 is handled by requiring C++11 on this library; should the
compiler being used not support C++11 then CMake will issue an error.
As of CMake 3.0 with CMP0042, MACOSX_RPATH is enabled by default.
Since the validated version used by jsoncpp is later than 3.0,
this is already covered.
The more general CMake way to handle library suffixing is to set
CMAKE_<CONFIG>_POSTFIX, so setting the Debug output suffix name should
be more correctly done by the caller or CMake configurer by setting
the desired value in CMAKE_DEBUG_POSTFIX.
* Modernize meson.build
* Make tests optional
* Use `files()` for quick sanity checks
* Bump version to 1.9.3
* Bump SOVERSION, as some functions were removed
and structs were changed, as determined by
libabigail.
* Add option JSONCPP_WITH_EXAMPLE
Allows to conditionally build examples as
it has been done for tests. Useful for packaging.
* Do not build example by default
We desire for jsoncpp to compile and be readily available
with older versions of cmake. The use of newer cmake
commands requires conditional statements so that older
strategies can be used with older versions of cmake.
Resolves: #1018
* update example directory
* modify some compile error.
* update with clang-format
* update
* update
* add_definitions("../include/json")
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Date: Wed Jul 10 21:26:16 2019 +0800
#
# On branch code_example
# Your branch is up-to-date with 'origin/code_example'.
#
# Changes to be committed:
# modified: example/CMakeLists.txt
#
* change CMakeLists.txt
* update streamWrite.cpp
* update
* Update readFromStream.cpp
* fix typo
* Cleanup versioning strategy
Currently, versioning is a mess. CMake and Meson have seperate build
version number storage locations, with no way of knowing you need to
have both. Plus, due to recent revisions the amalgamate script is broken
unless you build first, and may still be broken afterwards.
This PR fixes some issues with versioning, and adds comments clarifying
what has to be done when doing a release.
* Run clang format
* Update SOVERSION....
* Cleanup versioning strategy
Currently, versioning is a mess. CMake and Meson have seperate build
version number storage locations, with no way of knowing you need to
have both. Plus, due to recent revisions the amalgamate script is broken
unless you build first, and may still be broken afterwards.
This PR fixes some issues with versioning, and adds comments clarifying
what has to be done when doing a release.
* Run clang format
* Update SOVERSION....
Older versions of cmake, according to documentation:
https://cmake.org/cmake/help/v3.5/command/if.html , do not know
VERSION_LESS_EQUAL, just VERSION_LESS.
This leads to errors:
CMake Error at somewhere/jsoncpp/CMakeLists.txt:18 (if):
if given arguments:
"3.5.1" "VERSION_LESS_EQUAL" "3.13.1"
Unknown arguments specified
Resolves: #866
1) Improve travis build script for use outside travis.
Allow the script used for CI builds to also be used
locally in a similar manner to the CI use of the scrips
2) Add ctest compatible testing and CDASH support
Report testing and building results to
https://my.cdash.org/index.php?project=jsoncpp
NOTE: The new ctest infrastructure is not yet robust on winodws
Do no yet enable the new features for running test with ctest
on windows platform. The previous behaviors are maintainted,
but enhance test reporting from windows is not yet supported.
3) Add a cmake coverage testing option
Ensure that cmake builds on linux are tested.
Ensure that code coverage is reported.
4) Move conditional environment checking into the matrix
Avoid multiple places where conditional logic is used to
change compiler behavior. As more test environments are
created fromt the travis.yml matrix, all settings should be
obvious from that one location.
5) Tests with known regressions from the jsonchecker are suppressed
Tests that are known to pass with jsoncpp more lenient
syntax enforcement are exluded from tests in test/runjsontests.py
Allow configuring without cmake policy developer warnings
for a range of cmake versions.
This prevents the need to explicitly enumerate every new
policy for each new cmake version.
===
Moved setting of the CMAKE_CXX_STANDARD to before the project()
directive.
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
- if building as a submodule of another repository, installation of pkg-config files can fail because they may not be in the top-level binary directory
- changing ${CMAKE_BINARY_DIR} to ${CMAKE_CURRENT_BINARY_DIR} allow CMake to find the files for installation
'-pedantic' issues all warnings demanded by strict ISO C/C++; rejecting
extensions that do not follow ISO C/C++. Without this option, certain GNU
extensions and traditional C/C++ features are supported as well.
With this option enabled building jsoncpp fails with the musl toolchain on
x86 because of an incompatible posix_memalign declaration [1]. Without
'-pedantic' there is no error anymore and jsoncpp builds fine.
Add an option JSONCPP_WITH_STRICT_ISO to disable compilation with '-pedantic'
with GCC. If jsoncpp is build with the JSONCPP_WITH_WARNING_AS_ERROR option
'-pedantic-errors' is used instead.
[1] https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01425.html
* Clean up closing statements for if conditions, functions, macros,
and other entities. Newer versions of CMake do not require you to
redundantly respecify the parameters to the opening arguments.
-Werror shouldn't be used in released code since it can cause random build
failures on moderate warnings. It also depends on the used toolchain since
different toolchains may or may not print the same warnings.
Do not prepend ${prefix} to substituted includedir & libdir
in the pkg-config file -- if the paths are overriden by user, CMake puts
absolute paths there (even if user specifies a relative path). Instead,
use the absolute path provided by CMake and appropriately default
LIBRARY_INSTALL_DIR & INCLUDE_INSTALL_DIR to absolute paths with
${CMAKE_INSTALL_PREFIX} prepended.
Fixes: https://github.com/open-source-parsers/jsoncpp/issues/279
Signed-off-by: Michał Górny <mgorny@gentoo.org>
Currently JSONCPP_LIB_BUILD_SHARED variable is used as option to build static/shared libraries.
The current patch uses standard CMake variables for this.
Such a workaround is done in https://github.com/open-source-parsers/jsoncpp/issues/51
Current patch will make it generic.
This forces consistency, since they will be re-generated whenever
a git operation alters CMakelists.txt. They are still in the repo
because users might not actually run cmake.
To run these tests, in cmake build-dir:
make jsoncpp_check
TravisCI is now set to run these always.
For now, the test_json_lib unit-tests will still run.
issue #187
With set(CMAKE_*_OUTPUT_DIRECTORY) when using jsoncpp as a sub project,
the parent project's executables and libraries will also be outputed to
jsoncpp's directory. By removing this, it is up to the parent projects
to decide where to put their and jsoncpp's executables and libraries.
RPM-based distros such as Fedora or Mageia put 64bit libraries in /usr/lib64
while 32bit libraries go to /usr/lib. This is usually taken into account
in CMake projects using a LIB_SUFFIX parameter that can be set to "" or "64".
