[Tracker] (for review) VPATH builds and some other things

[Aleksander Morgado <aleksander lanedo com>]

Hi all,

So yesterday I started fixing GB#616808 to enable the possibility of
re-generating the PNG images in the doc from the dist tarball, and ended
up making possible VPATH builds in tracker.

The "vpath-build-review" branch is ready for review in gnome git

Some of the things I modified:

 * VPATH builds: Now you can compile tracker in a $(builddir) which is
not $(srcdir), so you can even have different $(builddir)s compiled with
different options and a keep a single $(srcdir). Apart from some gtk-doc
files which are always built in $(srcdir) (as reported in GB#127049 and
similar) all files generated during compilation are generated in
$(builddir). I tested VPATH builds both in the git sources and in the
dist tarball sources, and there seems to be no issue. Most of the
changes regarding the VPATH build support where just 2 things:
 a) adding -I$(top_builddir)/src in include paths in Makefile.am files
 b) adding MKHTML_OPTIONS=--path="$(abs_builddir)" so that gtk-doc also
checks the builddir for generated XML files to be included (version.xml
for example)

 * PNG files and XML files for the ontology documentation:  I enabled
the possibility of re-generating the PNG files from the dist tarball
sources (so dia files are distributed now), and also made the removal of
PNG images only in make maintainerclean (all this coming from
GB#616808). Then I used the same approach for the XML files generated
from the ontology descriptions, now they can be re-built from dist
tarball sources (needed to add some other files to the dist tarball),
and these will only be removed in make maintainerclean. I also moved the
generation of the PNG files and the XML files from the docs/tools
directory (where the tools to generate them are compiled) to the final
directory where we want these files to get generated
(docs/reference/ontology), thus avoiding several file copies. I believe
the generation of these PNG and XML files is now a little bit more
maintainable as there is only one Makefile.am using them.

Cheers!
-- 
Aleksander