Also see http://art.ubuntuforums.org/showthread.php?p=8590551

I am getting this error when trying to build Gnome Shell on the Ubuntu 9.10 based Linux Mint 8:

make  
make  all-recursive
make[1]: Går till katalogen "/home/rovanion/gnome-shell/source/gir-repository"
Making all in gir
make[2]: Går till katalogen "/home/rovanion/gnome-shell/source/gir-repository/gir"
/home/rovanion/gnome-shell/install/bin/g-ir-scanner -v --namespace Gdk --nsversion=2.0 \
	    --add-include-path=. --add-include-path=. \
             --include=Gio-2.0 \
             --include=cairo-1.0 \
             --include=Pango-1.0 \
	     --include=xlib-2.0 \
             --include=GdkPixbuf-2.0 \
	     --library=gdk-x11-2.0 \
	     --library=libgirepo-Gdk-custom.la \
	     --libtool="/bin/bash ../libtool" \
             --output Gdk-2.0.gir \
             --pkg gobject-2.0 \
             --pkg gio-2.0 \
             --pkg cairo \
             --pkg atk \
             --pkg pango \
             --pkg gdk-x11-2.0 \
             -DGDK_COMPILATION \
	     ./Gdk-custom.c ./Gdk-custom.h \
             `pkg-config --variable=includedir gdk-x11-2.0`/gtk-2.0/gdk/*.h
Traceback (most recent call last):

+ Trace 219892

make[2]: *** [Gdk-2.0.gir] Fel 1
make[2]: Lämnar katalogen "/home/rovanion/gnome-shell/source/gir-repository/gir"
make[1]: *** [all-recursive] Fel 1
make[1]: Lämnar katalogen "/home/rovanion/gnome-shell/source/gir-repository"
make: *** [all] Fel 2

I'm guessing that this occurs when one has Pango > 1.25.4, but not built with introspection support.  Hmm...I think what we need to do here is put a flag in the .pc file saying whether or not it was built with introspection.  This deps on 577347.

This doesn't seem fixable by additions or changes to Pango, for now, a check is going to have to be added to configure.ac that checks for the existance of the gir file, instead of going off pango.pc.

Hmm...I guess we could add a <!-- generated from gir-repository --> comment or such to the Pango.gir we generate, and then search for that if we do find a Pango.gir to know we need to rebuild it.

Even that's not quite right, becuase if you have a current gir-repository build, then you won't have that comment =(

Kind of a pile of evil...not sure.

I can't think of a way offhand to fix this truly correctly without changing Pango, but ideas welcome.

Duplicate of #605156?

-Mike.

(In reply to comment #8)
> Duplicate of bug 605156?

doesn't look like it to me.
===

Two ideas of fixing it:

 A) Compare timestamps on the installed pango gir (if any) and installed Pango library, if the Pango gir is older, generate a new Pango gir. Sounds a bit fragile.

 B) Unconditionally build and install the Pango gir and have a configure switch to disable it. There's no actual harm in overwriting the installed Pango gir, but it will break packaging via conflicts, hence the configure switch.

Created attachment 151290 [details] [review]
Add --with-skipped-gir-modules

Commit 7e443e50012004a2fafb caused us to skip building a .gir if
the relevant module was new enough to have introspection support;
however, this doesn't work if the module wasn't built with introspection.

As a stopgap, revert to building all .girs, but introduce a new
configure switch to skip building a list of given .girs.  This
is more suitable for OS builders who are in control of the compilation
of both modules.

Review of attachment 151290 [details] [review]:

Basic overview looks fine.

::: configure.ac
@@ +21,3 @@
 GOBJECT_INTROSPECTION_REQUIRE(0.6.7)
 
+AC_ARG_WITH([skipped-gir-modules], [AS_HELP_STRING([--with-skipped-gir-modules], [Comma-separated list of namespaces to skip building])], [], [])

You might want to add "e.g. 'Atk,Pango'" to this, since it's not clear the format otherwise.

Could this just be skipped-modules? This is in gir-repository after all...

@@ +34,2 @@
                   have_atk=true, have_atk=false)
+if echo $with_skipped_gir_modules | grep -q ,Atk,; then

Couple of things here

* This seems to only work for modules in the middle of the comma-separated list. Maybe echo ,$with_skipped_gir_modules, ?

* I think a shell function would increase the readability and maintainability here:

skip_module() {
   echo ,$with_skipped_gir_modules, | grep -q ,$1,
}

if skip_module Atk ; then
fi

* Seems like the PKG_CHECK_MODULES should be in the else.

if if skip_module Atk ; then
  have_atk=false
else
  PKG_CHECK_MODULES(ATK, atk >= 1.12.0,
                    have_atk=true, have_atk=false)  
fi

The way you have it now, it's going to show "checking for Atk" and an observent packager is going to think "my skip-modules configure didn't work" and confused.

(In reply to comment #11)
> 
> * This seems to only work for modules in the middle of the comma-separated
> list. Maybe echo ,$with_skipped_gir_modules, ?

See line 25.

> * I think a shell function would increase the readability and maintainability

Ok, I guess I'd have to look up what the portability implications are for functions.

(In reply to comment #12)
> (In reply to comment #11)
> > 
> > * This seems to only work for modules in the middle of the comma-separated
> > list. Maybe echo ,$with_skipped_gir_modules, ?
> 
> See line 25.

Oh, I looked for a line like that, missed it. Me be better to do it in the echo for readability reasons, at least if you encapsulate it in the shell function.

> > * I think a shell function would increase the readability and maintainability
> 
> Ok, I guess I'd have to look up what the portability implications are for
> functions.

Shell functions should fine (at least in the simple Bourne-style I used). The autoconf maintainers said a couple of years ago that they would start using them where appropriate - they had been avoiding them for "really ancient system" reasons.

Attachment 151290 [details] pushed as 5d0c6c8 - Add --with-skipped-gir-modules