Taskwarrior is a command line task list management utility with a multitude of features, developed as a portable open source project with an active and quite vast ecosystem of tools, hooks and extensions.
Taskwarrior is packaged on a wide range of Linux/Unix systems, Mac OS and Windows. Check out the latest available packages in repositories of your OS distribution of choice on Repology.
Alternatively, you can build Taskwarrior from source.
Taskwarrior - Command line To-Do Task Management.
The online documentation, downloads, news and more are available on our website, taskwarrior.org.
Taskwarrior has a lively community on many places on the internet.
Best place to ask questions is our discussions forum on Github. For other support options, take a look at taskwarrior.org/support
from https://github.com/GothenburgBitFactory/taskwarrior
-----
- CMake 3.22 or later
- gcc 7.0 or later, clang 6.0 or later, or a compiler with full C++17 support
- libuuid (if not on macOS)
- Rust 1.64.0 or higher (hint: use https://rustup.rs/ instead of using your system's package manager)
- python 3 (for running the test suite)
- pre-commit (for applying formatting changes locally)
- clangd or ccls (for C++ integration in many editors)
- rust-analyzer (for Rust integration in many editors)
The following documentation works with CMake 3.14 and later. Here are the minimal steps to get started, using an out of source build directory and calling the underlying build tool over the CMake interface. See the general CMake man pages or the cmake-documentation for more,
git clone https://github.com/GothenburgBitFactory/taskwarrior cd taskwarrior cmake -S . -B build -DCMAKE_BUILD_TYPE=RelWithDebInfo cmake --build build
Other possible build types can be Release
and Debug
.
This will build several executables, but the one you want is probably src/task
, located in the build
directory.
When you make changes, just run the last line again.
For only building the task
executable, use
cmake --build build --target task_executable
If a parallel build is wanted use
cmake --build build -j <number-of-jobs>
cmake -S . -B build-clang\
-DCMAKE_C_COMPILER=clang\
-DCMAKE_CXX_COMPILER=clang++
cmake --build build-clang
For running the test suite ctest is used.
Before one can run the test suite the task_executable
must be built.
After that also the test_runner
target must be build, which can be done over:
cmake --build build --target test_runner
Again you may also use the -j <number-of-jobs>
option for parallel builds.
Now one can invoke ctest
to run the tests.
ctest --test-dir build
This would run all the test in serial and might take some time.
ctest --test-dir build -j <number-of-jobs>
Further it is adviced to add the --output-on-failure
option to ctest
, to recieve a verbose output if a test is failing as well as the --rerun-failed
flag, to invoke in subsequent runs only the failed ones.
For this case one can use the -R <regex>
or --tests-regex <regex>
option to run only the tests matching the regular expression.
Running only the cpp
tests can then be achieved over
ctest --test-dir build -R cpp
or running the variant_*
tests
ctest --test-dir build -R variant
In order to find sporadic test failures the --repeat
flag can be used.
ctest --test-dir build -R cpp --repeat-until-fail 10
There are more options to ctest
such as --progress
, allowing to have a less verbose output.
They can be found in the ctest man page.
Note that any development should be performed using a git clone, and the current development branch. The source tarballs do not reflect HEAD, and do not contain the test suite. Follow the GitHub flow for creating a pull request.
from https://github.com/GothenburgBitFactory/taskwarrior/blob/develop/doc/devel/contrib/development.md
No comments:
Post a Comment