use the ones shiped from the latest cmake. which
* enables us to find the recent python intepreter and development files,
* find intepreter and development in a single `find_pacakge()` command,
simpler this way and less error prone.
and to accomodate this change:
* all `PYTHON${PYTHON_VERSION}_*` variables are renamed to
`Python${PYTHON_VERSION}_*` if we use `find_package(Python2...)` or
`find_package(Python3...)` to find python2 or python3 instead of using
`find_package(Python...)`.
* use "2" explicitly when using python2, as `Python_*` variables are not
defined anymore
* when compiling python support of ceph-mgr, continue using `Python_*`
variables. because we find the python interpreter and development
files using `find_pacakge(Python...)` for ceph-mgr.
Signed-off-by: Kefu Chai <kchai@redhat.com>
* rename genl to nl:
"genl" is not very specific without more context. and libnl is actually
a library suite. so it would be better if we can rename the library to
be found to "libnl", and by following the naming convention of CMake,
in this change, Findgenl.cmake is renamed to Findnl.cmake
* Findnl.cmake: support the component argument, in our specific case,
what we want is "libnl-genl" library, which is one of the libraries
offered by libnl. so let's just make it a component.
* Findnl.cmake: should pass the names of the required variables instead of
their values to `find_package_handle_standard_args()`. before this
change, we pass `GENL_LIBRARIES` to this function. it was correct at the
first glance. but it is not able to handle the case where case where
libnl-genl is not installed. so the fix is to pass all the names of
required library paths to this function. in this change, their name
are concatenated to a single variable -- `nl_LIBRARIES`, and the
value of this variable is passed to
`find_package_handle_standard_args()`. and the error message would
be more specific this way if libnl-genl is not found:
Could NOT find nl (missing: nl_genl_LIBRARY)
* Findnl.cmake: add nl::<component> as imported library, it helps the
consumer of these libraries to import them -- no need to
specify the `target_include_directories()` separately anymore.
* move the find_package() code to where it is used. it helps to improve
the readability.
* remove `HAVE_GENL` variable: it's not used anywhere.
* drop the messages of "Not using foobar", they do not help.
Signed-off-by: Kefu Chai <kchai@redhat.com>
The next patch adds netlink support to rbd-nbd. This patch just adds the
build related changes to bring in the netlink lib and test and build
against it.
Signed-off-by: Mike Christie <mchristi@redhat.com>
The next patch will add a WITH_RBD check to the LINUX check block so we
only check for the netlink libs when those 2 conditions are met, so this
moves the WIT_RBD option setup to before the LINUX check.
Signed-off-by: Mike Christie <mchristi@redhat.com>
If tcmalloc is in-use as the allocator and its version is less than 2.6.2,
it might be missing support for 'aligned_alloc'. This can result in the
glibc version of 'aligned_alloc' being used to allocate memory that is
then freed by tcmalloc -- resulting in a crash.
Fixes: http://tracker.ceph.com/issues/39703
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
There is a lot of good stuff going on here, but nobody is investing in xio
and it is not expected to be the path forward for RDMA. If that ever
changes, we can resurrect the code. Until then, let's clean up the tree
and reduce friction for changes going forward.
Signed-off-by: Sage Weil <sage@redhat.com>
cmake,rgw: make amqp support optional
Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
Reviewed-by: Yuval Lifshitz <yuvalif@yahoo.com>
Reviewed-by: Willem Jan Withagen <wjw@digiware.nl>
rabbitmq-c is not a header-only library. so we need to ensure that the
library is also around before linking against it. in this change:
* move the detection down to where librabbitmq is used
* add FindRabbitMQ.cmake for find_package(RabbitMQ)
* s/rabbitmq/RabbitMQ::RabbitMQ/ as the latter is an alias library
target, which has more information attached to it.
Signed-off-by: Kefu Chai <kchai@redhat.com>
We can re-enable after we branch. For N, though, there is no point in dragging
in the dependencies and implying there is something that works.
Signed-off-by: Sage Weil <sage@redhat.com>
This patch introduces new FIO engine which main goal is to test
bare Ceph messenger transport layer performance. Engine submits
requests in async manner and polls for completion. Completions
are kept in lockless ring buffer so on hot path no muteces or
conditions are used in order to get maximum bandwidth and less
latency.
Signed-off-by: Roman Penyaev <rpenyaev@suse.de>
It is rather had to overide a once set timeout during CTesting.
This is the best next compromise. Disadvantage is that a rebuild
is required.
But it helps in my Jenkins testing timely catching run-away programs.
Signed-off-by: Willem Jan Withagen <wjw@digiware.nl>
We are currently hosting the grafana dashboards in our repo but we do
not install them. This patch adds the cmake support.
Signed-off-by: Boris Ranto <branto@redhat.com>
Ceph requires C++17 support from compiler. This means gcc 7.x being
minimal version supported.
This also allows to fail quick on Debian 'stretch' with it's gcc 6.3
compiler.
Signed-off-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
* refs/pull/24020/head:
*: set missing CLOEXEC on opened fds
msg: set O_NONBLOCK on file status flags
Reviewed-by: Kefu Chai <kchai@redhat.com>
Reviewed-by: Sage Weil <sage@redhat.com>
If CEPH_DEBUG_MUTEX is defined, use the [recursive_]mutex_debug classes
that implement lockdep and a bucnh of other random debug checks. Also
typedef ceph::condition_variable to std::condition_variable_debug, which
adds addition assertions and debug checks.
If CEPH_DEBUG_MUTEX is not defined, then use the bare-bones C++ std::mutex
primitives... or as close as we can get to them.
Since the [recursive_]mutex_debug classes take a string argument for the
lockdep piece, define factory functions ceph::make_[recursive_]mutex that
either pass arguments to the debug implementations or toss them out.
Signed-off-by: Sage Weil <sage@redhat.com>
Otherwise these descriptors may leak across execve() during e.g. MDS respawn.
Fixes: http://tracker.ceph.com/issues/35850
Signed-off-by: Patrick Donnelly <pdonnell@redhat.com>
by default, debian packaging creates ${prefix}/lib/x86_64-linux-gnu for
multi-arch support. but FindBoost.cmake does not check in such a
directory if $BOOST_ROOT is set. in this change, this directory is added
to the search path.
Signed-off-by: Kefu Chai <kchai@redhat.com>
