the new behavior of get_target_property(<var> <target> SOURCES) will be
enforced in future versions of cmake, so let ready for this change now
by removing the generator expressions from the returned source file
list.
Signed-off-by: Kefu Chai <kchai@redhat.com>
so cmake will error on "non-existent dependency in add_dependencies", we
add dependency on CONFIGURE_FILE() output, which is wrong, as its output
is not a target, and is generated when cmake runs. so remove them from
dependencies.
regarding to ceph_ver.h, its path is also wrong. it is created under
${CMAKE_BINARY_DIR}/src/include. so this is another reason to remove it.
Signed-off-by: Kefu Chai <kchai@redhat.com>
* to pick up the fix of https://svn.boost.org/trac10/ticket/11622
* also the boost::python's library name now includes the version suffix
of python version, so update BuildBoost.cmake accordingly.
Signed-off-by: Kefu Chai <kchai@redhat.com>
to silence the warnings like
CMake Warning at CMakeLists.txt:73 (find_package):
By not providing "Findgflags.cmake" in CMAKE_MODULE_PATH this project
has
asked CMake to find a package configuration file provided by "gflags",
but
CMake did not find one.
Could not find a package configuration file provided by "gflags" with
any
of the following names:
gflagsConfig.cmake
gflags-config.cmake
Add the installation prefix of "gflags" to CMAKE_PREFIX_PATH or set
"gflags_DIR" to a directory containing one of the above files. If
"gflags"
provides a separate development package or SDK, be sure it has been
installed.
Signed-off-by: Kefu Chai <kchai@redhat.com>
because FindBoost.cmake defines Boost::boost as the target for header
only dependencies.
due to the limit of cmake < 3.1, this only applies to cmake > 3.1
Signed-off-by: Kefu Chai <kchai@redhat.com>
test/fio: enable objectstore FIO plugin building without the need to install and build FIO source code
Reviewed-by: Casey Bodley <cbodley@redhat.com>
Reviewed-by: Kefu Chai <kchai@redhat.com>
so the dependencies can be included when linking against the one which
depends on them. for example, libboost_filesystem depends on
libboost_system, if we don't link against the latter, linker will bail
out when linking an executable using Boost::filesystem.
Signed-off-by: Kefu Chai <kchai@redhat.com>
the boost override for add_library() does not work for ALIAS targets:
CMake Error at cmake/modules/BuildBoost.cmake:227 (add_dependencies):
Cannot add target-level dependencies to alias target "Seastar::seastar".
Signed-off-by: Casey Bodley <cbodley@redhat.com>
after bumping up the required boost version, old copy of boost in
src/boost will not work. so we need to error out early.
Signed-off-by: Kefu Chai <kchai@redhat.com>
* user-config.jam is the suggested way for adding toolset for Boost.Build.
* always specify toolset when running b2, so we can build boost with
specified compiler instead of the default one guessed by boost building system.
Signed-off-by: Kefu Chai <kchai@redhat.com>
* cmake/modules/BuildSPDK.cmake: add lvol
* cmake/modules/BuildDPDK.cmake: add pci and bus_pci
* ceph.spec.in, cmake/modules/BuildSPDK.cmake, debian/control:
re-introduce libuuid dependency, as 17.07 added lvol. and the latter
depends on uuid.
* cmake/modules/BuildSPDK.cmake: avoid introducing local variable of
`iface_libs`.
* cmake/modules/patch-dpdk-conf.sh: disable
CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES, this option introduces the
balanced allocation of memory. but it also requires libnuma-dev.
let's disable it for now.
Signed-off-by: Kefu Chai <kchai@redhat.com>
config.hpp does not exist if boost is not configured. so a boost source
directory unpacked from dist tarball does not have this file. the
bootstrap.sh instead, it is used to create the necessary config files
for jam.
Signed-off-by: Kefu Chai <kchai@redhat.com>
DPDK requires GNU Make. see
spdk/dpdk/doc/guides/freebsd_gsg/build_dpdk.rst. so, we should use the
configured make program to do the job.
Signed-off-by: Kefu Chai <kchai@redhat.com>
otherwise, the default gcc will be used, and the $CMAKE_C_COMPILER
passed to the outer CMakeLists.txt won't kick in. moreover, if the
building script (ceph.spec for instance) could set the $PATH, and
expect that the CMakeLists.txt will use the toolchain executables
in the $PATH to build Ceph, distutils will continue using the default
$CC for linking the python bindings, on UNIX it will be gcc in the
new shell's $PATH, because we are using `install(CODE "... execute_process(
...))` for installing the python bindings. apparently, this is not
expected. because the new shell's $PATH is very likely different
from the one changed by the building script. to address this, we
should always specify the `$LDSHARED` env var explicitly.
also, pass env vars using `ENV{}` instead of the `env` command to
workaround the issue of https://cmake.org/pipermail/cmake/2015-December/062216.html,
because it's not straightforward to set environment variables with
spaces in the them using cmake. and because one cannot use add_custom_target()
in the script mode of cmake. this leave me only limited options to
fix this issue.
Signed-off-by: Kefu Chai <kchai@redhat.com>
otherwise it's always true, even if the libaries are not found. also
the cmake output will be wrong without this change:
without this change, it is:
-- Found gperftools: GPERFTOOLS_TCMALLOC_LIBRARY;GPERFTOOLS_TCMALLOC_MINIMAL_LIBRARY;GPERFTOOLS_PROFILER_LIBRARY (found version "2.5.93")
with this change, it would be:
-- Found gperftools: /tmp/gperf/lib/libtcmalloc.so (found version "2.5.93")
Signed-off-by: Kefu Chai <kchai@redhat.com>
there is chance that its "patch" version is empty. in that case, do not
include it in its version string. otherwise, we will have something
like:
Found gperftools:
GPERFTOOLS_TCMALLOC_LIBRARY;GPERFTOOLS_TCMALLOC_MINIMAL_LIBRARY;GPERFTOOLS_PROFILER_LIBRARY
(found version "2.4.#define TC_VERSION_PATCH """)
when running cmake
Signed-off-by: Kefu Chai <kchai@redhat.com>
the commit d406f228 in gperf implements a c11 feature used by a
recent change in rocksdb: 16e03882, which uses aligned_alloc().
and 16e03882 in rocksdb was merged after v5.7 was tagged, while
16e03882 in gperf was merged after v2.6.1 was tagged.
because aligned_alloc() is not implemented by tcmalloc until the
not-yet-released 2.6.2, if we call aligned_alloc() in an application
linked against tcmalloc, what gets called will be the glibc's
aligned_alloc(). but if we free() the memory chunk allocated by
aligned_alloc(), the tcmalloc's implementation kicks in, then
InvalidFree() is called, because the memory chunk being freed was
allocated by tcmalloc. in short, "mixing allocators", quote from
Dan Mick.
in rocksdb, aligned_alloc() is used if _ISOC11_SOURCE is defined, this
makes sense, because aligned_alloc() is a C11 function. we could avoid
using it by not defining _ISOC11_SOURCE. but as long as _GNU_SOURCE is
defined, glibc defines _ISOC11_SOURCE. and libstdc++ requires
_GNU_SOURCE, because it uses a fair amount of GNU extensions.
Fixes: http://tracker.ceph.com/issues/21422
Signed-off-by: Kefu Chai <kchai@redhat.com>
