Refactor CMake add_tox_test to automatically add py27 and/or py3 to
provided toxenvs.
Refactor tox.ini:
- Remove requirements-{py27,py3}.txt, as python release dependant
packages can be handled with PEP 508 syntax.
- Remove develepment dependencies from requirements.
- Move pycodestyle settings to separate section.
- Add flake8 check and other checkers (rst, naming, etc). Some of them
are commented out for future clean-ups (Ceph trackers have been opened)
- Pycodestyle removed, as flake8 is a wrapper for pycodestyle.
- Add instafail plugin to report failures immediately
- Add timeout plugin to limit max run time (sometimes test_tasks hangs)
- Remove unused dependencies (lru_cache, pluggy)
Test and code linting fixes:
- Unused imports
- Fixes to HACKING.rst
Doc:
- Update HACKING.rst
Add conftest.py to mock imported modules (rados, rbd, cephfs), and mock
also rados Error and OSError Exceptions.
Fixes: https://tracker.ceph.com/issues/40487
Fixes: https://tracker.ceph.com/issues/41152
Signed-off-by: Ernesto Puerta <epuertat@redhat.com>
* add two optional keyword parameters to `add_tox_test()`
* use the default `TOX_PATH` parameter instead passing it explicitly,
as it is always `${CMAKE_CURRENT_SOURCE_DIR}`
* drop the code to guess the tox envs in `run_tox.sh`, and always pass
them explicitly in CMake script using the `--tox-envs` argument.
Signed-off-by: Kefu Chai <kchai@redhat.com>
so we can prepare the venv for tox with `make tests`. and it's optional,
as run_tox.sh will check for it and setup a venv if it's not around.
Signed-off-by: Kefu Chai <kchai@redhat.com>
since we dropped the support of xenial, we now have the luxury of using
newer CMake! and by using CMake 3.10.2, we can prevent libfmt from
assuming that we are using C++11, and hence set `CMAKE_CXX_STANDARD` to
11, which will literally append `-std=gnu++11` to `CMAKE_CXX_FLAGS`.
the last `-std` option passed to `g++` takes precendence.
since we've switched over to C++17, and we are using C++17 features.
so, using cmake older than 3.8 breaks the build. because it is CMake 3.8
which stared support `CMAKE_CXX_STANDARD` 17.
- for bionic: https://packages.ubuntu.com/bionic/cmake : 3.10.2
- for CentOS7:
https://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/c/ : 3.13.5
so in this change,
* bump up the required version to v3.10.2
* cleanups to wipe out the workaround for lower CMake versions
* use `PROJECT_VERSION` defined by `project()` command instead of
`VERSION` explicitly defined.
Signed-off-by: Kefu Chai <kchai@redhat.com>
if `distutils_install_module("foo" ...)` is called mutiple times with
different python version, `foo-clone` will be added multiple times as a
custom target. which is not allowed:
add_custom_target cannot create target "foo-clone" because another
target with the same name already exists.
Signed-off-by: Kefu Chai <kchai@redhat.com>
allow `distutils_*()` functions to choose the python according to this
parameter, instead of implicitly using the variable of ${PYTHON_VERSION}
inherited from the caller.
Signed-off-by: Kefu Chai <kchai@redhat.com>
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>
this option was introduced by cmake 3.1, and we require cmake 3.5.1, so
we can use it without using the homebrew solution.
Signed-off-by: Kefu Chai <kchai@redhat.com>
use the combination of add_custom_command() and add_custom_target() to
build cython extensions to avoid rebuilding the cython extension
everytime we run "make"
Signed-off-by: Kefu Chai <kchai@redhat.com>
so add_custom_target() has better idea what is generated. if any target
will use it, it can be used as a dependency.
Signed-off-by: Kefu Chai <kchai@redhat.com>
The issue has been fixed upstream under lockfree commit
7e23dac52d08ed1a099de9a6fb8bcdefbb06d2da but is not yet available in
a boost release.
Signed-off-by: Jason Dillaman <dillaman@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>
* isal needs nasm, which is a new dependency. so let's disable it
at this moment.
* vhost requires DPDK compiled with vhost enabled. but it's disabled
when we compile DPDK.
Signed-off-by: Kefu Chai <kchai@redhat.com>
* update execenv to remove "app", the targets ending with "app" changed
to the ones without "app" now.
* pass CC by make variables not env variables, otherwise the default
`cc` is used
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>
as the flags should be a string, not a list
tested using
cmake -DCMAKE_LINKER=gold -DWITH_ASAN=ON -DWITH_ASAN_LEAK=ON \
-DCMAKE_BUILD_TYPE=Debug
on ubuntu xenial
without this change, cmake will fail with following warning:
CMake Error at src/CMakeLists.txt:112 (message):
The compiler /usr/bin/c++ has no C++17 support.
-- Configuring incomplete, errors occurred!
Signed-off-by: Kefu Chai <kchai@redhat.com>
ninja scan the build dependencies differently than GNU make, so we need
to specify the product of `ExternalProject_Add()`. with this change,
we can build `vstart-base` without building the ExternalProject
separately.
Signed-off-by: Kefu Chai <kchai@redhat.com>
* modules/BuildDPDK.cmake: always use "make"
* modules/BuildSPDK.cmake: always use "make"
DPDK only support "make". if user wants to use other generator than
"make", we will fail to build DPDK support. so we should always use
"make" here. and before using "make", we need to detect it.
* cmake/modules/BuildRocksDB.cmake: use cmake for build
* src/compressor/zstd/CMakeLists.txt: use cmake for build
just use whatever generator use specifies, and use ${CMAKE_COMMAND}
for building the specified target, no need to repeat
${CMAKE_GENERATOR} for building the target.
Signed-off-by: Kefu Chai <kchai@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>
Commit 3bde34af8a removed cython 0.29's subinterpreter check when
building the various python modules during `make`, but unforunately
they're *rebuilt* during `make install`, with the rebuild overwriting
the original build. The original fix was of course missing from the
install stage...
Fixes: https://tracker.ceph.com/issues/38788
Signed-off-by: Tim Serong <tserong@suse.com>
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>
