The cmake target of an alias may not be an Imported Target.
Always build the msgpackc target and only build the msgpackc-static
target if both should be build to fix issue #801. Thereby the type
(shared or static) of the msgpackc target depends on the build
configuration.
There are three switches to build static/shared libraries.
Here is the logic.
If BUILD_SHARED_LIBS is defined
If BUILD_SHARED_LIBS is ON
build only shared-library
Else
build only static-library
Endif
Else
If MSGPACK_ENABLE_SHARED is ON (default)
build shared-library
Endif
If MSGPACK_ENABLE_STATIC is ON (default)
build static-library
Endif
Endif
Here is common settings:
If you want to build both static/shared libraries, don't set switches.
If you want to build only shared-library, set BUILD_SHARED_LIBS=ON.
If you want to build only static-library, set BUILD_SHARED_LIBS=OFF.
Since FULL_PATH_NAMES = YES, Doxygen includes the full build path to the
file in the documentation. This is most prevalent in the <title>
attribute for a file.
Setting STRIP_FROM_PATH = ${CMAKE_CURRENT_SOURCE_DIR}/include means that
only the relevant portion of the path (that which the user would need to
use) is included.
--- a/msgpack_8h.html 2018-05-12 14:03:34.098715879 -0400
+++ b/msgpack_8h.html 2018-05-12 14:04:17.386349607 -0400
@@ -5,7 +5,7 @@
<meta http-equiv="X-UA-Compatible" content="IE=9"/>
<meta name="generator" content="Doxygen 1.8.13"/>
<meta name="viewport" content="width=device-width, initial-scale=1"/>
-<title>MessagePack for C: /home/jamessan/src/debian.org/pkg-vim/msgpack-c/include/msgpack.h File Reference</title>
+<title>MessagePack for C: msgpack.h File Reference</title>
<link href="tabs.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="dynsections.js"></script>
Hello, here are a few changes to the default CFLAGS
## Why Werror
With each new compiler version, your code "break" and fail to compile. It is true that it's a sometime a "bug" in the code and need visibility to get fixed. However, Werror should *always* be a local CFLAGS and not a project one, see Google for endless people arguing back and forth and removing Werror is now the prevalent winner of that argument. In the latest GCC, it fails to compile because the fwrite result in unchecked. Even if you fix this in new releases, you cannot fix the past and all existing releases used in stable products suddenly fail to compile, wasting everybody time.
## Why -g
This should be decided by the one who compiles the code. Some people want small and pre-stripped binaries and appending this to the CFLAGS breaks the standard way of achieving this. Prepend it if you wish, but please do not append it.
## Why -O3
On many systems with limited cache or higher memory latency, `O3` is slower than `O2`, so IMHO it should not be hardcoded. In my case I used `Os` and it's faster. The `O` value should be left to the system, not hardcoded.
Add support for CMake find_package command to msgpack. The package
exports the two targets msgpackc-static and msgpackc if shared is
enabled. The CMake find_package command works after installation
of msgpack and during build of another project which adds msgpack
as sub project via add_subdirectory command.
Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com>
When you add or remove .h .hpp .c files in the msgpack-c library, run
make_file_list.sh. It generates (overwrites) Files.cmake for cmake and
src/files.mk for autotools. They are a part of repository managed
files. Files.cmake is included by CMakeLists.txt and src/files.mk is
included by src/Makefile.am.
If MSGPACK_DISABLE_LEGACY_CONVERT is defined, msgpack::object::convert(T*) is removed.
Added MSGPACK_DISABLE_LEGACY_CONVERT to build system and documents.
Please define MSGPACK_DISABLE_LEGACY_CONVERT and update your code as follows:
Replace
int i;
obj.convert(&i); // Removed pointer version
with
int i;
obj.convert(i); // Reference version
libmsgpack.[a|so] is the library file for C++.
libmsgpackc.[a|so] is the library file for C.
Since version 1.0.0, the C++ parts of msgpack-c is a header only
library. So libmsgpack.* shouldn't be generated.
On the autotools building environment, removed libmsgpack.*
generation. On the cmake building environment, replaced libmsgpack.*
with libmsgpackc.* and set so-version to 2.0.0.
In aa79fc2f, the SOVERSION was bumped to 4 for autoconf-based builds,
but was left at 3 for CMake builds. This shouldn't differ based on
which tool is used to build msgpack-c.
Signed-off-by: James McCoy <jamessan@jamessan.com>
Stefan Herbrechtsmeier