TC 0.7.0 introduces a new `TaskData` type that maps to Taskwarrior's
`Task` type more cleanly. It also introduces the idea of gathering lists
of operations and "committing" them to a replica.
A consequence of this change is that TaskChampion no longer
automatically maintains dependency information, so Taskwarrior must do
so, with its `TDB2::dependency_sync` method. This method does a very
similar thing to what TaskChampion had been doing, so this is a shift of
responsibility but not a major performance difference.
Cxx is .. not great. It is missing a lot of useful things that make a
general-purpose bridge impractical:
- no support for trait objects
- no support for `Option<T>` (https://github.com/dtolnay/cxx/issues/87)
- no support for `Vec<Box<..>>`
As a result, some creativity is required in writing the bridge, for
example returning a `Vec<OptionTaskData>` from `all_task_data` to allow
individual `TaskData` values to be "taken" from the vector.
That said, Cxx is the current state-of-the-art, and does a good job of
ensuring memory safety, at the cost of some slightly awkward APIs.
Subsequent work can remove the "TDB2" layer and allow commands and other
parts of Taskwarrior to interface directly with the `Replica`.
Two of these used EXPFAIL which, because nothing is interpreting the TAP
output, does not work. So, that functionality is removed, and the
expected-to-fail bits are commented out or removed.
There was a conditional on the filename in `bash_tap.sh` which caused it
to not actually do anything and just run the test as a simple shell
script. That, too, has been removed.
Taskwarrior uses "expire" to refer to deletion of tasks past their
"until" date, so let's use `purge` to link this semantically to the
`task purge` command.
* move taskchampion-lib to src/tc/lib, remove the rest
* update references to taskchampion
* Use a top-level Cargo.toml so everything is consistent
* apply comments from ryneeverett
* fix path to task executable in pyton tests
The current approach would copy the current files into the `build/test`
directory. Updating the paths according to the custom user setup.
By the copy I appended `.py` to have a clear visible distingtion which
ones are the python tests.
As soon as a source file in the normal directory is changed, it is
copied over and the corresponding file is updated.
From now on the python tests would need to get run in the according
build directory.
* reflect the current build instruction in PR template
* update paths and globing in run_all
* add line break for every cpp test
* remove .gitignore in test folder
As now all the auxillary files such as `all.log` as well as the
executables are present in the `build` directory there is no longer a
need to ignore them.
* update paths in python test scripts and enable deactivated
* remove .py extension when copy to build
Further remove glob pattern for `*.t.py` tests.
* remove accidentally added template.t from test files
* Add support for cloud sync, specifically GCP
This adds generic support for sync to cloud services, with specific
spuport for GCP. Adding others -- so long as they support a
compare-and-set operation -- should be comparatively straightforward.
The cloud support includes cleanup of unnecessary data, and should keep
total space usage roughly proportional to the number of tasks.
Co-authored-by: ryneeverett <ryneeverett@gmail.com>
* Link test executables using system frameworks on Darwin
On an M1 MBP, running `cmake . && make test` yields the error
```
[ 69%] Linking CXX executable tc.t
Undefined symbols for architecture arm64:
"_CFRelease", referenced from:
_$LT$iana_time_zone..platform..system_time_zone..SystemTimeZone$u20$as$u20$core..ops..drop..Drop$GT$::drop::hcd3964de9573de30 in libtc_rust.a(iana_time_zone-0e2714c6ff24f5bb.iana_time_zone.4cacef0c-cgu.15.rcgu.o)
"_CFStringGetBytes", referenced from:
iana_time_zone::platform::string_ref::StringRef$LT$T$GT$::to_utf8::h39971b546d587152 in libtc_rust.a(iana_time_zone-0e2714c6ff24f5bb.iana_time_zone.4cacef0c-cgu.13.rcgu.o)
"_CFStringGetCStringPtr", referenced from:
iana_time_zone::platform::string_ref::StringRef$LT$T$GT$::as_utf8::h8bb5c2c0d091ded1 in libtc_rust.a(iana_time_zone-0e2714c6ff24f5bb.iana_time_zone.4cacef0c-cgu.13.rcgu.o)
"_CFStringGetLength", referenced from:
iana_time_zone::platform::string_ref::StringRef$LT$T$GT$::to_utf8::h39971b546d587152 in libtc_rust.a(iana_time_zone-0e2714c6ff24f5bb.iana_time_zone.4cacef0c-cgu.13.rcgu.o)
"_CFTimeZoneCopySystem", referenced from:
iana_time_zone::platform::system_time_zone::SystemTimeZone:🆕:hc42d30609914d79d in libtc_rust.a(iana_time_zone-0e2714c6ff24f5bb.iana_time_zone.4cacef0c-cgu.15.rcgu.o)
"_CFTimeZoneGetName", referenced from:
iana_time_zone::platform::system_time_zone::SystemTimeZone::name::h44947ee6deb3339a in libtc_rust.a(iana_time_zone-0e2714c6ff24f5bb.iana_time_zone.4cacef0c-cgu.15.rcgu.o)
"_SecRandomCopyBytes", referenced from:
ring::rand::darwin::fill::h0ad94d66d4e1a222 in libtc_rust.a(ring-e5f87a2e334d4c6a.ring.a21bac31-cgu.4.rcgu.o)
"_kSecRandomDefault", referenced from:
ring::rand::darwin::fill::h0ad94d66d4e1a222 in libtc_rust.a(ring-e5f87a2e334d4c6a.ring.a21bac31-cgu.4.rcgu.o)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[3]: *** [test/tc.t] Error 1
make[2]: *** [test/CMakeFiles/tc.t.dir/all] Error 2
make[1]: *** [test/CMakeFiles/test.dir/rule] Error 2
```
This change resolves the error by updating the targets in
test/CMakeLists.txt to link against the CoreFoundation and Security
frameworks when building under Mac OS.
* Link executables against CoreFoundation and Security frameworks on Mac OS
* Rename test_osx.sh to test_macos.sh
---------
Co-authored-by: Dathan Bennett <dathanb@netflix.com>
This uses CMake to build a simple Rust library (in `src/tc/rust`) that
just re-exports everything from the `taskchampion-lib` crate.
The C++ wrappers then wrap this into C++ objects with proper lifecycle
maintenance, in the `tc` namespace.
The C++ wrappers are incomplete, and missing methods are tagged with
"TODO". These will be added as needed.
The data from the server is read via Task::parseJSON, not Task::parse.
This also reverts the tests for Task::parse, and adds new tests for this
specific issue.
- This policy is no longer necessary because CMake issue #16062, which caused
incorrect warnings to be shown, has been resolved in 3.11.0.
- Thanks to Janik Rabe
- Improved the handling when parsing blank lines and empty task in the data, so
that instead of the message:
Taskwarrior no longer supports file format 1, originally used between 27
November 2006 and 31 December 2007.
We now see:
Unrecognized Taskwarrior file format or blank line in data.
- Merged t2.t.cpp into t.t.cpp.
