Fixed gir install path variables

[adogadkin]

Changed girdir and typelibsdir to depend upon configured prefix settings, similarly to other MATE projects.
Fixes #647.

[cwendling]

Doesn't something like this work?

diff --git a/configure.ac b/configure.ac
index 65d1c05d..0e664eb9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -360,8 +360,8 @@ if test "$enable_introspection" = "yes"; then
   G_IR_SCANNER="$($PKG_CONFIG --variable=g_ir_scanner gobject-introspection-1.0)"
   G_IR_COMPILER="$($PKG_CONFIG --variable=g_ir_compiler gobject-introspection-1.0)"
   G_IR_GENERATE="$($PKG_CONFIG --variable=g_ir_generate gobject-introspection-1.0)"
-  GIRDIR="$($PKG_CONFIG --variable=girdir gobject-introspection-1.0)"
-  GIRTYPELIBDIR="$($PKG_CONFIG --variable=typelibdir gobject-introspection-1.0)"
+  GIRDIR='${datadir}'"$($PKG_CONFIG --define-variable=datadir= --variable=girdir gobject-introspection-1.0)"
+  GIRTYPELIBDIR='${libdir}'"$($PKG_CONFIG --define-variable=libdir= --variable=typelibdir gobject-introspection-1.0)"
 fi
 
 AC_SUBST([G_IR_SCANNER])

Actually I would say we should use introspection.m4 instead of rolling our own, it hasn't been changed since 2015, so it's probably a safe enough dependency. The only downside, if it is one, is that we'd depend on it to generate the build system (e.g. a Git build would require introspection.m4 on the system) -- or we distribute a copy.

At any rate, if this change was to be merged, I'd at least like the definitions for those variables to be removed as well, there's not point in keeping them.

[adogadkin]

Doesn't something like this work?

Yes, it works and is similar to what they do in introspection.m4 you linked. Interestingly though, in documentation they still suggest defining target path variables as

girdir = $(datadir)/gir-1.0
typelibdir = $(libdir)/girepository-1.0

despite INTROSPECTION_GIRDIR and INTROSPECTION_TYPELIBDIR containing the right values. I don't know whether there is a reason for that.

Actually I would say we should use introspection.m4 instead of rolling our own, it hasn't been changed since 2015, so it's probably a safe enough dependency. The only downside, if it is one, is that we'd depend on it to generate the build system (e.g. a Git build would require introspection.m4 on the system) -- or we distribute a copy.

I have no experience with autotools, so I'll try playing a bit with introspection.m4 to see if I can make things work at all. Which is preferable - shipping it with atril or expecting it as an external dependency? Older Gnome documentation recommended the former.

[lukefromdc]

Probably best to ship it, if GNOME still supports using introspection with autotools that might not last

[cwendling]

Yes, it works and is similar to what they do in introspection.m4 you linked. Interestingly though, in documentation they still suggest defining target path variables as

Oh, right… weird, but that's probably fine then. Either way you like.

[adogadkin]

Changed GIR configuration to use introspection.m4 and Makefile.introspection provided by gobject-introspection.

The checks in introspection.m4 enable building introspection support if possible by default, which is different from original implementation always defaulting to --enable-introspection=no. Everything else should stay the same.

As for shipping these files within atril - after going a bit through other MATE projects I found several of them (e.g. mate-menus, caja ...) using these files as external dependency. All those projects will have to adapt as well, should Gnome remove support for autotools. At that point these files would probably go into mate-common, so for now I think it is better to keep uniformity and let atril expect them to be present as part of gobject-introspection.

[lukefromdc]

Changed GIR configuration to use introspection.m4 and Makefile.introspection provided by gobject-introspection.

The checks in introspection.m4 enable building introspection support if possible by default, which is different from original implementation always defaulting to --enable-introspection=no. Everything else should stay the same.

As for shipping these files within atril - after going a bit through other MATE projects I found several of them (e.g. mate-menus, caja ...) using these files as external dependency. All those projects will have to adapt as well, should Gnome remove support for autotools. At that point these files would probably go into mate-common, so for now I think it is better to keep uniformity and let atril expect them to be present as part of gobject-introspection.

Since we already depend on these elsewhere no reason to do differently here. I concur if this is ever a problem they should go once into mate-common instead of being duplicated in many packages