Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unit testing cmake #2268

Merged
merged 17 commits into from
Sep 28, 2018
Merged

Unit testing cmake #2268

merged 17 commits into from
Sep 28, 2018

Conversation

jngrad
Copy link
Member

@jngrad jngrad commented Sep 17, 2018

Unit tests for CMake output files: espresso binaries, Python bindings, Doxygen documentation and Sphinx documentation. Part of the make check workflow. If we ever need a shell-independent solution, there is kward/shunit2.

Regarding #2245, the install test checks make install DESTDIR=/some/dir, yet for make install we need write rights for /usr/local/lib, which the end user doesn't have without sudo. We could either:

  1. make the CMake tests exclusive to the CI workflow, testing make install becomes trivial
  2. keep the make check workflow as-is and add a CI-specific target check_cmake_CI to test make install

Solution 2 allows external developers to run CMake tests with make check, while solution 1 requires them to find the CI-specific CMake target and adapt it to run without sudo rights.

Note: the CMake variables PYTHON_FOUND and other *_FOUND variables defined in /CMakeLists.txt seem out of scope in /testsuite/cmake/CMakeLists.txt. Is there any way to import them? At the moment I re-declared them in /testsuite/cmake/CMakeLists.txt (can break if we update version numbers in /CMakeLists.txt):

find_package(PythonInterp REQUIRED)
find_package(Doxygen)
find_package(Sphinx 1.6.6)

  * Create /testsuite/cmake/CMakeLists.txt
    using /testsuite/python/CMakeLists.txt
  * Split CMake unit tests in 4 files
  * Handle the setup() function inside CMake with add_custom_target(),
    for example: `add_custom_target(setup_doxygen COMMAND make doc
    WORKING_DIRECTORY ${CMAKE_BINARY_DIR})`
@mkuron
Copy link
Member

mkuron commented Sep 17, 2018

for make install we need write rights for /usr/local/lib

You could change the destination to some other place that‘s writable, like /tmp. There is a CMake variable for that.

@hmenke
Copy link
Member

hmenke commented Sep 17, 2018

cmake -DCMAKE_INSTALL_PREFIX=/tmp/espresso ..
make
make install

add_dependencies(check_python pypresso python_test_data check_python_serial)

add_dependencies(check check_python)
add_subdirectory(python)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we lost git history here... better: git mv CMakeLists.txt python

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see no difference between testsuite/CMakeLists.txt in upstream and testsuite/python/CMakeLists.txt in this PR. Commit c273d64 shows everything was renamed with git mv. Commit 8e80916 applied the changes by junghans to preserve git history.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah git is not good in tracking moves...

@fweik fweik added this to the Espresso 4.0.1 milestone Sep 18, 2018
@KaiSzuttor
Copy link
Member

the *FOUND variables are available in the subdirectories, for PythonInterp it's PYTHONINTERP_FOUND

@jngrad
Copy link
Member Author

jngrad commented Sep 18, 2018

@KaiSzuttor: thanks, I see the issue with *_FOUND variables now
@mkuron, @hmenke: good idea! CI now uses /tmp to test the standard installation procedure. This test is disabled for the user, as it would collide with the normal installation workflow (CMake environment variables set by the user would be erased). Is it necessary to add a cleanup function, or is /tmp automatically cleaned after CI?

@jngrad jngrad force-pushed the unit-test-cmake branch 3 times, most recently from 0d760c3 to bb89f74 Compare September 18, 2018 17:10
@KaiSzuttor
Copy link
Member

We use docker containers / VM, so you dont have to worry about /tmp

@jngrad jngrad force-pushed the unit-test-cmake branch 2 times, most recently from 5a65077 to 8e2833a Compare September 18, 2018 18:29
@codecov
Copy link

codecov bot commented Sep 18, 2018

Codecov Report

Merging #2268 into python will decrease coverage by <1%.
The diff coverage is n/a.

Impacted file tree graph

@@          Coverage Diff           @@
##           python   #2268   +/-   ##
======================================
- Coverage      71%     71%   -1%     
======================================
  Files         377     377           
  Lines       18946   18925   -21     
======================================
- Hits        13585   13526   -59     
- Misses       5361    5399   +38
Impacted Files Coverage Δ
...rc/core/utils/serialization/CUDA_particle_data.hpp 50% <0%> (-50%) ⬇️
src/core/constraints/Constraint.hpp 66% <0%> (-34%) ⬇️
src/core/short_range_loop.hpp 85% <0%> (-15%) ⬇️
src/core/EspressoSystemInterface.cpp 83% <0%> (-9%) ⬇️
src/core/PartCfg.hpp 91% <0%> (-9%) ⬇️
src/core/lattice.cpp 82% <0%> (-7%) ⬇️
src/core/object-in-fluid/membrane_collision.hpp 14% <0%> (-4%) ⬇️
src/core/domain_decomposition.cpp 88% <0%> (-4%) ⬇️
src/core/Vector.hpp 89% <0%> (-3%) ⬇️
src/core/algorithm/verlet_ia.hpp 97% <0%> (-3%) ⬇️
... and 18 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3059d2d...5812159. Read the comment docs.

@jngrad
Copy link
Member Author

jngrad commented Sep 18, 2018

Good to know:

  • depending on the linux distribution, Python modules are installed in pythonX.Y/dist-packages or pythonX.Y/site-packages
  • mpiexec and its siblings from the Open MPI suite can stall indefinitely when running a bash script containing two subprocesses with the syntax (set -e; python -m ...). Ctrl+C does not terminate the process, Ctrl+Z hangs the process but does not terminate it, such that you cannot cleanup files created by the unit tests until you SIGTERM mpiexec in htop. I've disabled MPI for CMake tests.

@codecov
Copy link

codecov bot commented Sep 18, 2018

Codecov Report

Merging #2268 into python will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@          Coverage Diff           @@
##           python   #2268   +/-   ##
======================================
  Coverage      71%     71%           
======================================
  Files         380     380           
  Lines       18975   18975           
======================================
  Hits        13588   13588           
  Misses       5387    5387
Impacted Files Coverage Δ
src/core/grid_based_algorithms/lb.hpp 71% <0%> (ø) ⬆️
src/core/lattice.cpp 89% <0%> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3c195e3...71fa626. Read the comment docs.

@jngrad
Copy link
Member Author

jngrad commented Sep 18, 2018

The CMake tests are now included in /maintainer/CI/build_cmake.sh and are running in CI, however Sphinx needs some troubleshooting. Depending on the container, either Sphinx extensions are missing:

Could not import extension sphinxcontrib.bibtex (exception: No module named bibtex)
make[7]: *** [doc/sphinx/CMakeFiles/sphinx] Error 1

or it cannot load a Python module:

Warning, treated as error:
autodoc: failed to import module 'espressomd.visualization_mayavi'; the following exception was raised:
No module named 'particle_data'
make[7]: *** [doc/sphinx/CMakeFiles/sphinx] Error 2
doc/sphinx/CMakeFiles/sphinx.dir/build.make:57: recipe for target 'doc/sphinx/CMakeFiles/sphinx' failed

@KaiSzuttor
Copy link
Member

The latter is an issue of install as sphinx does not seem to find necessary files. I’m also not so sure if we want to test sphinx and doxygen for the install target since we deploy both with each merge via the CI.

@jngrad
Copy link
Member Author

jngrad commented Sep 19, 2018

Agreed, let's just test installation. Now most containers pass CI, however maxset-python3, clang:6.0 and intel:15 seem unable to copy python files into the build directory, despite being configured with $with_python_interface set to true.

@jngrad jngrad force-pushed the unit-test-cmake branch 2 times, most recently from 7638520 to 57d8d12 Compare September 22, 2018 17:25
@jngrad
Copy link
Member Author

jngrad commented Sep 22, 2018

Alright, it was just a race condition in the Makefile for two containers. I also found an interaction with Clang's UBSan that prevents python from importing the espressomd module after installation in /tmp:

File "/tmp/espresso-unit-tests/lib/python2.7/dist-packages/espressomd/__init__.py", line 23, in <module>
    import espressomd._init
ImportError: /builds/espressomd/espresso/build/src/core/grid_based_algorithms/liblbgpu_cuda.so: undefined symbol: __ubsan_vptr_type_cache

Not really sure why a shared object in the build directory would be called at that point (linking error?), nor why the error doesn't show up before installation. I get a different pointer error when compiling espresso with UBSan on my Ubuntu machine. UBSan is currently enabled only in container clang-6.0; I've changed the CMake test to skip the import test when UBSan is enabled.

Then, code coverage stopped working for container cuda-maxset (yet unit tests pass).

@KaiSzuttor
Copy link
Member

maybe we should try to get the test pass also with UBSan. @mkuron can you please have a look?

@mkuron
Copy link
Member

mkuron commented Sep 25, 2018

You need the LD_PRELOAD from the pypresso script in order to inject ubsan into python itself.

@jngrad
Copy link
Member Author

jngrad commented Sep 25, 2018

Using pypresso instead of python2 exits the interpreter on my machine with UndefinedBehaviorSanitizer: failed to parse suppressions instead of raising warnings. I tried removing lines in /tools/ubsan-suppressions.txt to check if one of them caused the parsing error, but the message did not change (except when the file is completely empty, causing a read error).

@KaiSzuttor
Copy link
Member

@jngrad could you please have a look at my changes?

@jngrad
Copy link
Member Author

jngrad commented Sep 25, 2018

Looks good to me.

testsuite/cmake/test_doxygen.sh Outdated Show resolved Hide resolved
testsuite/cmake/test_sphinx.sh Outdated Show resolved Hide resolved
@KaiSzuttor
Copy link
Member

@jngrad i don't understand the interplay between your cmake tests and the failing coverage commands, any idea?

@jngrad
Copy link
Member Author

jngrad commented Sep 26, 2018

I've got the same coverage command issue in #2280 despite only changing comment lines in that PR.

@jngrad
Copy link
Member Author

jngrad commented Sep 26, 2018

Our GitLab instance crashed on Saturday. It automatically restarted afterwards, then a few hours later I got the coverage command issue here (57d8d12) and on the other PR (8fedeb9). The issue seems random, as your commit 31b76f8 passed while my next commit 71fa626 did not (although I just re-started the failed test with container cuda-shanchen and it now passes).

@jngrad
Copy link
Member Author

jngrad commented Sep 26, 2018

Maybe this is relevant: I used git commit --amend --no-edit; git push --force in this PR and a similar rebase operation the other PR, while CI was still running in both cases. I'll halt any pending CI before push --force in the future.

@fweik
Copy link
Contributor

fweik commented Sep 28, 2018

@KaiSzuttor @jngrad What is the status on this? You should merge this soon to avoid merge conflicts.

@KaiSzuttor KaiSzuttor merged commit c1d850e into espressomd:python Sep 28, 2018
RudolfWeeber pushed a commit to RudolfWeeber/espresso that referenced this pull request Oct 17, 2018
@jngrad jngrad deleted the unit-test-cmake branch January 18, 2022 12:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants