Bug 177107 – gnome-base/gnome-vfs-2.18.1 depends unconditionally on gtk-doc

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Alessandro Guido 2007-05-05 00:27:24 UTC]

as subject says, gnome-base/gnome-vfs-2.18.1 pulls in a dependency on gtk-doc, which is not useful at all to the normal user.
Instead, it should use:
$(use_enable doc gtk-doc)
and a conditional rdep on gtk-doc

Reproducible: Always

[Comment 1 Jakub Moc (RETIRED) 2007-06-10 13:19:16 UTC]

Alessandro, you have a patch for this? As it is now, automake plain fails w/o gtk-doc:

<snip>
gtk-doc.make:7: GTK_DOC_USE_LIBTOOL does not appear in AM_CONDITIONAL
doc/Makefile.am:91:   `gtk-doc.make' included from here
gtk-doc.make:43: ENABLE_GTK_DOC does not appear in AM_CONDITIONAL
doc/Makefile.am:91:   `gtk-doc.make' included from here
gtk-doc.make:136: ENABLE_GTK_DOC does not appear in AM_CONDITIONAL
doc/Makefile.am:91:   `gtk-doc.make' included from here
</snip>

[Comment 2 Alessandro Guido 2007-06-27 17:42:44 UTC]

(In reply to comment #1)
> Alessandro, you have a patch for this? As it is now, automake plain fails w/o
> gtk-doc:
> 
> <snip>
> gtk-doc.make:7: GTK_DOC_USE_LIBTOOL does not appear in AM_CONDITIONAL
> doc/Makefile.am:91:   `gtk-doc.make' included from here
> gtk-doc.make:43: ENABLE_GTK_DOC does not appear in AM_CONDITIONAL
> doc/Makefile.am:91:   `gtk-doc.make' included from here
> gtk-doc.make:136: ENABLE_GTK_DOC does not appear in AM_CONDITIONAL
> doc/Makefile.am:91:   `gtk-doc.make' included from here
> </snip>
> 

I see the ebuild regenerates the configure script, I only tried launching ./configure --disable-gtk-doc and worked fine. I'll try to cook up a patch

[Comment 3 Mart Raudsepp 2007-07-30 03:47:14 UTC]

This already worked in 2.18.0.1. I'm not sure why compnerd backed this out for 2.18.1. I'm probably going to just add the workaround back, as there is no reason given in ChangeLog or anywhere for the change.

[Comment 4 Mart Raudsepp 2007-07-30 05:21:02 UTC]

Discussed it with compnerd. It was changed because the method that was used is very fragile to break. A better solution is to get the m4 file from elsewhere, for example by putting it on mirrors and pulling it into a m4 directory and including that in the eautoreconf run, or just including it in $FILESDIR and copying in place.
Ideally of course we wouldn't need to patch configure.in to even need the eautoreconf in the first place.
I am going with stabling 2.18.0.1 for now, that still uses the fragile method for working around the dependency.
We need to get a solution for this bug ASAP, as gnome-vfs-2.18.1 improves copying speed a lot (and therefore copying of files in nautilus) compared to 2.18.0.1.

[Comment 5 Saleem Abdulrasool (RETIRED) 2007-07-30 06:51:38 UTC]

committed a kludge to get around the macro issue..it will suffice for now, as it it less fragile than what we were previously doing.

[Comment 6 Mart Raudsepp 2007-07-30 06:59:52 UTC]

Thanks. Going with 2.18.1 for stabling then.