87 lines
3.4 KiB
Plaintext
87 lines
3.4 KiB
Plaintext
"Higher level section"_Build.html - "LAMMPS WWW Site"_lws - "LAMMPS
|
|
Documentation"_ld - "LAMMPS Commands"_lc :c
|
|
|
|
:link(lws,http://lammps.sandia.gov)
|
|
:link(ld,Manual.html)
|
|
:link(lc,Commands_all.html)
|
|
|
|
:line
|
|
|
|
Development build options (CMake only) :h3
|
|
|
|
The CMake build of LAMMPS has a few extra options which are useful during
|
|
development, testing or debugging.
|
|
|
|
:line
|
|
|
|
Verify compilation flags :h4,link(compilation)
|
|
|
|
Sometimes it is necessary to verify the complete sequence of compilation flags
|
|
generated by the CMake build. To enable a more verbose output during
|
|
compilation you can use the following option.
|
|
|
|
-D CMAKE_VERBOSE_MAKEFILE=value # value = no (default) or yes :pre
|
|
|
|
Another way of doing this without reconfiguration is calling make with variable VERBOSE set to 1:
|
|
|
|
make VERBOSE=1 :pre
|
|
|
|
:line
|
|
|
|
Address, Undefined Behavior, and Thread Sanitizer Support :h4,link(sanitizer)
|
|
|
|
Compilers such as GCC and Clang support generating binaries which use different
|
|
sanitizers to detect problems in code during run-time. They can detect "memory leaks"_https://clang.llvm.org/docs/AddressSanitizer.html,
|
|
code that runs into "undefined behavior"_https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html of the
|
|
language and "data races"_https://clang.llvm.org/docs/ThreadSanitizer.html in threaded code.
|
|
|
|
The following settings allow you enable these features if your compiler supports
|
|
it. Please note that they come with a performance hit. However, they are
|
|
usually faster than using tools like Valgrind.
|
|
|
|
-D ENABLE_SANITIZE_ADDRESS=value # enable Address Sanitizer, value = no (default) or yes
|
|
-D ENABLE_SANITIZE_UNDEFINED=value # enable Undefined Behaviour Sanitizer, value = no (default) or yes
|
|
-D ENABLE_SANITIZE_THREAD=value # enable Thread Sanitizer, value = no (default) or yes
|
|
:pre
|
|
|
|
:line
|
|
|
|
Code Coverage and Testing :h4,link(testing)
|
|
|
|
We do extensive regression testing of the LAMMPS code base on a continuous
|
|
basis. Some of the logic to do this has been added to the CMake build so
|
|
developers can run the tests directly on their workstation.
|
|
|
|
NOTE: this is incomplete and only represents a small subset of tests that we run
|
|
|
|
-D ENABLE_TESTING=value # enable simple run tests of LAMMPS, value = no (default) or yes
|
|
-D LAMMPS_TESTING_SOURCE_DIR=path # path to lammps-testing repository (option if in custom location)
|
|
-D LAMMPS_TESTING_GIT_TAG=value # version of lammps-testing repository that should be used, value = master (default) or custom git commit or tag
|
|
:pre
|
|
|
|
If you enable testing in the CMake build it will create an additional target called "test". You can run them with:
|
|
|
|
make test
|
|
:pre
|
|
|
|
The test cases used come from the lammps-testing repository. They are
|
|
derivatives of the examples folder with some modifications to make the run
|
|
faster.
|
|
|
|
You can also collect code coverage metrics while running the tests by enabling
|
|
coverage support during building.
|
|
|
|
-D ENABLE_COVERAGE=value # enable coverage measurements, value = no (default) or yes :pre
|
|
|
|
This will also add the following targets to generate coverage reports after running the LAMMPS executable:
|
|
|
|
make test # run tests first!
|
|
make gen_coverage_html # generate coverage report in HTML format
|
|
make gen_coverage_xml # generate coverage report in XML format
|
|
:pre
|
|
|
|
These reports require GCOVR to be installed. The easiest way to do this to install it via pip:
|
|
|
|
pip install git+https://github.com/gcovr/gcovr.git :pre
|
|
:pre
|