1. 17 Feb, 2019 1 commit
  2. 05 Dec, 2018 1 commit
  3. 13 Nov, 2018 3 commits
  4. 05 Nov, 2018 1 commit
  5. 13 Oct, 2018 2 commits
    • Carlos Garnacho's avatar
      build: Use install_data() to install libtracker-sparql .deps vapi file · 277b9ba4
      Carlos Garnacho authored
      We generate that file ourselves, so configure_file() is unneeded as the
      file requires no substitutions. Fixes a warning on recent meson, as the
      configuration should not be empty.
    • Carlos Garnacho's avatar
      build: Fixes to docs generation · 86a4a666
      Carlos Garnacho authored
      The docs were not going through gtkdoc-scangobj, and the libtracker-sparql
      docs were just looking in source dir while it should also look for gtk-doc
      comments in generated files from vala.
      Now that we're there, use include_directories() to get rid of relative
  6. 11 Oct, 2018 2 commits
    • Carlos Garnacho's avatar
      Revert "build: Do not link libtracker-data.so to libtracker-sparql.so" · 20b9f367
      Carlos Garnacho authored
      Works with meson 0.48.0, but not with the versions in CI/build.gnome.org.
      Not cool, meson. We'll have to linger with broken internal library
      dependencies till I restructure the src/libtracker-* mess, or 0.48.0 gets
      This reverts commit 6799d903.
    • Carlos Garnacho's avatar
      build: Do not link libtracker-data.so to libtracker-sparql.so · 6799d903
      Carlos Garnacho authored
      Even though libtracker-data uses types from libtracker-sparql, this
      is the wrong way around. However, doing the right thing here still
      breaks because meson is playing smart here and passes --no-undefined
      for every shared library by default, so build breaks with obviously
      undefined symbols.
      Correct the dependency tree to be exactly how it was with autotools,
      and override b_lundef when building libtracker-data to leave the
      borrowed symbols undefined. The gaps will be filled in because
      everyone must link with libtracker-sparql.
      Closes: #44
  7. 06 Oct, 2018 1 commit
  8. 20 Sep, 2018 1 commit
  9. 09 Sep, 2018 3 commits
  10. 04 Sep, 2018 1 commit
  11. 29 Aug, 2018 2 commits
  12. 15 Aug, 2018 1 commit
  13. 11 Aug, 2018 3 commits
    • Sam Thursfield's avatar
      libtracker-sparql: Don't use 'namespace' as a parameter name · bb726349
      Sam Thursfield authored
      This header was unusable from C++ code as 'namespace' is a reserved
      keyword there.
      Based on a patch by Santtu Lakkala from
    • Sam Thursfield's avatar
      tracker_domain_ontology_get_domain() should return only the domain name · 9840ab01
      Sam Thursfield authored
      We should be consistent about what the name of a Tracker domain actually
      is. In the domain rule we specify Domain=org.freedesktop (for the
      default rule) or Domain=org.example.App (for a custom domain). But
      internally tracker_domain_ontology_get_domain() would return
      org.freedesktop.Tracker1 or org.example.App.Tracker1, i.e. the domain
      name now has '.Tracker1' appended.
      This does make sense in most cases, but it means there's no way to get
      the actual name of the domain from a TrackerDomainOntology object. This
      commit changes the existing function to not append '.Tracker1' in the
      value it returns, which means that function can now be used to get the
      base name of the domain. The assumption is that callers are normally
      appending stuff to this base name anyway so it's not much extra effect
      to also append the '.Tracker1' component if needed.
      libtracker-common is internal to Tracker so this doesn't constitute a
      public API break.
    • Sam Thursfield's avatar
      Add tracker_sparql_connection_get/set_dbus_connection() · eb24ea93
      Sam Thursfield authored
      Currently it's only possible to open a TrackerSparqlConnection to
      an instance of Tracker that is running on the session-wide message bus.
      There are use cases for running the Tracker daemons on a private
      session bus though. In fact it's necessary to do this if you want to
      set up a custom domain without having to become root and create .service
      files in /usr/share/dbus-1/services. It would also be useful for the
      functional-tests to be able to use libtracker-sparql instead of having
      to talk directly to Tracker's D-Bus API.
  14. 03 Aug, 2018 1 commit
    • Carlos Garnacho's avatar
      libtracker-sparql: delete TrackerResource elements one by one · a25f186f
      Carlos Garnacho authored
      Creating a single query for all values to delete can only work if
      all values have a match. As soon as a value is already missing,
      the query would just bail out as there's no real match.
      We want to delete every value individually regardless of other
      properties, so decompose the single delete into multiple individual
      Fixes "Unable to insert multiple values for subject..." warnings
      as the insertion queries would rely on single-valued properties being
      cleared beforehand.
      Closes: #28
  15. 15 Jul, 2018 1 commit
  16. 22 Apr, 2018 1 commit
    • Sam Thursfield's avatar
      meson: Install generated headers without needing a script · 7bcf86e4
      Sam Thursfield authored
      This script dates from a long time ago when Meson lacked ways to install
      generated headers.
      This fixes an issue where `ninja install` in tracker.git triggers a
      rebuild of lots of stuff from tracker-miners.git, which happened because
      the mtime of the installed generated headers would become newer than the
      build files in tracker-miners.git and cause ninja to rebuild them all.
  17. 20 Apr, 2018 1 commit
  18. 24 Jan, 2018 1 commit
  19. 23 Jan, 2018 1 commit
  20. 29 Sep, 2017 1 commit
  21. 22 Sep, 2017 2 commits
  22. 07 Aug, 2017 1 commit
  23. 19 Jul, 2017 3 commits
    • Carlos Garnacho's avatar
      build: Cleanup TRACKER_COMPILATION defines from c_args · 5022b3ff
      Carlos Garnacho authored
      It is now defined globally, so can removed from specific targets.
    • Carlos Garnacho's avatar
      build: Unbreak meson build · e10fbf33
      Carlos Garnacho authored
      The change in 1b312602 added somewhat clumsy meson support. The
      C-side vapi is now required by the Vala-side vapi, but only the latter
      is included when building the rest of the libraries. Since we can't
      tell the build to ditch the vala vapi and include our merged/spiced up
      tracker-sparql-2.0.vapi file, add a dependency on the C vapi that we can
      add on the selected places.
      A side effect of including the unfixed vapis is that includes point
      to internal files, so make sure everything gets TRACKER_COMPILATION
      when building to circumvent it.
    • Carlos Garnacho's avatar
      libtracker-sparql: Fix tracker-sparql-2.0.vapi generation · 2957dd7d
      Carlos Garnacho authored
      It would be left partly including headers that must not be accessed
      directly. Also, ensure that we look for the C vapi file in srcdir for
      both meson and autotools.
  24. 16 Jul, 2017 1 commit
    • Emmanuele Bassi's avatar
      build: Add generated enumeration files to BUILT_SOURCES · 50dc250a
      Emmanuele Bassi authored
      Dependency tracking in Automake is a side effect of compilation. This
      means two things:
        * headers are ignored when it comes to building dependencies, even
          when listed inside sources for a binary target
        * generated headers included inside source files are not used
          as a dependency until compilation of the source file completes
      If binary target L depends on a source file C, and that source file
      includes a generated header H, there is no guarantee that the header
      H will be available by the time source file C is built, because the
      dependency is extracted from C itself, not from the list of sources.
      Additionally, any header H does not count towards the dependency
      resolution because headers are only used for ancillary features, like
      extracting tags.
      For this reason, Automake has `BUILT_SOURCES`.
      This is a bit of obscure corner of Automake that trips up many who are
      not practitioners of the Dark Arts.
      More information is available here:
  25. 11 Jul, 2017 4 commits