| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since recently, GVDB repository includes a minimal meson.build
file to allow building as a subproject without additional
hassles (e.g. shipping supporting files at /subprojects/repofiles/)
Drop our internal copy of GVDB in favor of a subproject built
through Meson.
Since we're updating many years across, there has been GVDB API
updates that we need to adapt to: GvdbTable is no longer a refcounted
object, and gvdb_table_walk() is no longer offered to iterate across
values.
These largely affect our own set of GVDB tests though, the test
for gvdb_table_walk() was dropped, and so is the ref/unref one
(it basically does the same than gvdb/flat_strings, after dropping
the refcounting). These remaining tests stay useful, and should
ideally move into the GVDB repository, so it can run as a separate
suite here.
|
| |
|
|
|
|
|
| |
We want to stop making this a separate static library, but internal to
libtracker-sparql. As a first step, move it into libtracker-sparql and
use a cooler yet more honest name, this really is the core of our
SPARQL and RDF storage implementation.
|
| |
|
|
|
|
| |
Very far in the day, this used to be an optional module. But it no
longer is, and we expect that sqlite has FTS5 builtin, so can just
drop the static library separation and merge it together.
|
| | |
|
| |
|
|
| |
One more step towards the unification of libtracker-sparql.
|
| |
|
|
|
|
| |
This makes the src/ dir a bit less cluttered.
Closes https://gitlab.gnome.org/GNOME/tracker/-/issues/195
|
| |
|
|
|
|
|
|
|
|
|
| |
The library API is versatile enough that we no longer need a central
service. A minimum replacement of this process would consist of a
connection created through tracker_sparql_connection_new(), plus an
endpoint exported through tracker_endpoint_dbus_new().
From the tracker perspective this ends the move to a decentralized
scheme, with no central store and users being conscious about the
services they connect to.
|
| |
|
|
|
|
|
|
|
|
|
| |
According to Debian code search, it's accumulated 0 users outside of
tracker-miners. If everyone is relying on either tracker-miner-fs/rss
or implementing their own minimal abstraction (TrackerMinerFS is a
complex object, but the others are all fairly shallow), it does not
make sense to drag this as public API anymore.
This code moves into tracker-miners, and every user is expected to
consume and insert data using the sparql library.
|
| |
|
|
|
|
|
|
| |
This API gained some users, but it is solely used to deal with
one miner (tracker-miner-fs, obviously). In those circumstances,
it's about just as practical to poke well-known DBus names,
certainly there's little users beyond tracker CLI for generic
management of miners.
|
| |
|
|
| |
Fixes an issue in tracker-store
|
| | |
|
| |
|
|
| |
This is being split to its own package
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
It was cool when Tracker search was barely integrated anywhere.
Nowadays, it's nothing but an aging showcase app (eg. was conceived
in the gtk2 days and barely ported to gtk3, and it shows everywhere).
If you want a modern and capable search UI, try Nautilus. If you
are outraged that tracker-needle is gone and ended up here, by all
means be my guest, reset to the parent of this commit and take it
out of tree. If you join #tracker I'll gladly give you advise on
how could it be brought up-to-date. But our hands are full, sorry,
we leave cool UIs to others.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a mix of store and miner features which can't be assumed to go
together. It is better to leave configuration UI up to the environment,
in the GNOME case this is gnome-control-center search panel.
For settings that fall in the cracks, or for environments that don't
integrate Tracker search in their configuration UI, there's the rather
capable dconf-editor which will provide all toggles, and will explain
them better than any UI we may have.
In the future the CLI tools might gain some configuration subcommand,
but it will not be a graphical UI.
|
|
|
See <http://mesonbuild.com/> for information about Meson.
Remaining issues:
* There's no `make dist` equivalent. We currently produce release
tarballs containing the output files of the Vala compiler. We need
to think through whether we can stop doing that. Shipping the
generated .c files does make the Vala preprocessor useless so
it would be good if we can stop.
* The Firefox, Thunderbird, Evolution and Nautilus plugins are not
built
* https://github.com/mesonbuild/meson/issues/671 -- means we can't
depend on tracker_common_dep in most places and have to manually
set link_with, include_directories and sources instead.
* https://github.com/mesonbuild/meson/issues/1469 -- without this we
have to install generated Vala headers using a script
* https://github.com/mesonbuild/meson/issues/1229 -- means adding
the #include guard to libtracker-sparql/tracker-generated-no-checks.h
is a pain
* The test suite has some spurious failures.
Here's a rough speed comparison.
Meson:
time sh -c 'meson .. --prefix=/opt/tracker-meson -D bash_completion=/opt/tracker-meson/share/bash-completion -Dsystemd_user_services=/opt/tracker-meson/lib/systemd/user -Ddbus_services=/opt/tracker-meson/share/dbus-1/services && ninja-build -j 4 && ninja-build install'
real 1m8.194s
user 2m16.962s
sys 0m20.532s
Autotools:
time sh -c './configure --prefix=/opt/tracker-autotools --with-bash-completion-dir=/opt/tracker-autotools/share/bash-completion --with-session-bus-services-dir=/opt/tracker-autotools/share/dbus-1/services --disable-nautilus-extension && make -j 4 && make install'
real 2m37.750s
user 4m37.214s
sys 0m54.806s
Plus 30+ seconds of ./autogen.sh first.
Note that Meson builds may fail if your source tree has generated files
from an Autotools build in there. If you see errors about duplicate
definitions, first try cleaning your source tree (use `git clean -dfx`,
but make sure you commit any work first!!)
|
