This merge pulls in the changes that Leon developed over the course of
the last months which change the binaries to actually be libraries with
a _very_ minimal binary surface. This enables us to actually generate
commandline completion scripts with clap without doing any fancy
file-include magic in a build.rs script.
From the original request-pull message (Mon, 24 Jun 2019 21:48:51 +0200):
> This patch is yet another attempt at bringing CLI completion to this
> workspace project. The details are explained in the commit message.
>
> Advantages of this approach include:
> - Use of standard dependency management features (`cargo install`
> compatible)
> - Exposing further "binary" business logic to other Rust crates as a
> library
> - (Possibly) hard linking the "binary" into the main imag binary, so
> only one binary needs to be shipped. This should improve startup time,
> and the Runtime instance could even be reused. I'd favor this
> approach, while making it all configurable via features and still
> searching the $PATH to allow bash-scripts etc. to provide imag
> subcommands.
>
> However, this *could* increase binary size, I didn't perform any
> measures (at least when not only using in the build script but in the
> main binary as well). Anyhow, with LTO enabled this shouldn't matter if
> the dependencies aren't used.
Some patches were added by me before the merge, because Leon did not
check whether the tests still work (just minimal adjustments, see the
log).
Also, one change was made to the final patchset send by Leon, which was
a fixup of the Copyright date in bin/core/imag/build.rs. This change
does not appear in the commit logs because it was just bumping the year
from 2018 to 2019 in the Copyright header. This was acked by Leon in a
private conversation.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
This is yet another attempt to bring CLI completion to this workspace
project.
It uses the subcommand-libraries implementing the ImagApplication
trait to expose the clap CLI interface. This way, no file import magic
happens, it's all just regular dependencies, which should also work
with a regular `cargo install`.
Signed-off-by: Leon Schuermann <leon@is.currently.online>
To re-add the imag-binary CLI completion, as well as to enable
building a single imag containing all of the subcommands, this commit
introduces an ImagApplication trait to be implemented by all imag
binary crates. The binary crates will be converted to libraries, with
an additional binary target. This enables standalone and single binary
builds.
On its own, this commit doesn't do much, but rather it paves the way
to dynamically interacting with the imag uis/clis using a
library-crate interface.
Signed-off-by: Leon Schuermann <leon@is.currently.online>
After moving an entry, the entry should _not_ be in the cache. This is
just a decision that has to be made, whether we cache the moved entry or
not. I decided to not cache because it is results in less code.
After that check, we get the entry from the backend and then we can
check whether the entry is in the cache, which is then should be.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
When moving an entry, what we did is copying the entry inside the
backend abstraction (the hashmap) from one key to another.
But as the entry itself does also encode its location, we actually have
to rewrite the entire entry. This patch fixes this.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
This is a bugfix for a bug in Store::move_entry_by_id():
The old entry was not removed after the new one was created.
The bug is a bit subtle. The issue was, that the internal cache held
open a reference to the old entry (as StoreEntry object) and when that
object got drop()ed, the contents of the entry were written to disk,
which resulted in the old entry being recreated.
This patch rewrites the function to behave well. The most critical part
is that we do not check whether the old entry is borrowed with
`hsmap.get()` but rather `hsmap.remove()`. The trick here is that the
`StoreEntry` object is dropped in the moment the check is done, clearing
the cached object and flushing it to the backend (the disk).
After that, we continue doing the filesystem operation and the cache is
clean.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
