After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 562310 - glib 2.18.3: /bin/sh: line 1: gtkdoc-rebase: command not found
glib 2.18.3: /bin/sh: line 1: gtkdoc-rebase: command not found
Status: RESOLVED FIXED
Product: gtk-doc
Classification: Platform
Component: general
unspecified
Other All
: Normal normal
: 1.12
Assigned To: gtk-doc maintainers
gtk-doc maintainers
: 565322 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-11-26 08:09 UTC by Ryan Schmidt
Modified: 2009-07-01 23:56 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Ryan Schmidt 2008-11-26 08:09:37 UTC
Please describe the problem:
glib's "make install" procedure checks if gtkdoc-rebase exists, and if so, calls it. But the check to see if gtkdoc-rebase exists is done in a way that does not work on Mac OS X (at least, not in Tiger), so it still tries to call gtkdoc-rebase, even if it does not exist, which leads to:

[snip]
-- Installing ./html/left.png
-- Installing ./html/mainloop-states.gif
-- Installing ./html/right.png
-- Installing ./html/style.css
-- Installing ./html/tools.html
-- Installing ./html/up.png
/bin/sh: line 1: gtkdoc-rebase: command not found

and the install aborts at that point. glib 2.18.2 ignored errors from gtkdoc-rebase, but glib 2.18.3 no longer ignores those errors (the "-" before gtkdoc-rebase has been removed in the Makefiles) so now this error interrupts the install whereas before it was silently skipped over.

Steps to reproduce:
On Mac OS X with its standard "which" command, try to "make install" glib 2.18.3.

Actual results:
/bin/sh: line 1: gtkdoc-rebase: command not found


Expected results:
gtkdoc-rebase should not be called if it does not exist

Does this happen every time?
yes

Other information:
On Mac OS X (at least in Tiger), "which" returns exit code 0, regardless of whether it found or did not find the specified utility. glib does this:

! which gtkdoc-rebase >/dev/null 2>&1 || gtkdoc-rebase ...

The way you can use "which" that works on Mac OS X:

if [ -x "`which gtkdoc-rebase`" ]
then
  gtkdoc-rebase ...
fi
Comment 1 Matthias Clasen 2008-11-28 20:35:25 UTC
This falls into the responsibility of gtk-doc.
Comment 2 Stefan Sauer (gstreamer, gtkdoc dev) 2008-11-29 16:25:02 UTC
This is fixed in gtkdoc-1.11.
Comment 3 OBATA Akio 2008-12-22 10:42:11 UTC
Why is this fixed in gtkdoc-1.11?
glib 2.18.3 contains gtk-doc.make from gtk-doc-1.11,
and it still have same codes mentioned in this Bug.
Comment 4 Stefan Sauer (gstreamer, gtkdoc dev) 2008-12-24 09:49:35 UTC
Ahh, got it, thats a bug in macosx then.
Comment 5 OBATA Akio 2008-12-24 13:01:43 UTC
It is not a bug, just a behavior of MacOS's which command is different than you expect (and you can see also Bug#565322 on Solaris).
There is no standard definition of which command.
Comment 6 Stefan Sauer (gstreamer, gtkdoc dev) 2008-12-29 19:59:32 UTC
*** Bug 565322 has been marked as a duplicate of this bug. ***
Comment 7 Stefan Sauer (gstreamer, gtkdoc dev) 2008-12-29 20:13:03 UTC
I sent a mail to gtk-doc list summarizing the issue
http://mail.gnome.org/archives/gtk-doc-list/2008-December/msg00001.html

Apparently I need input from macos and solaris people how to do this in a portable way.

One thing that I still don't get is why if fails the build for you. The whole rule is prefixed with '-' after all.
Comment 8 Stefan Sauer (gstreamer, gtkdoc dev) 2009-01-07 16:05:29 UTC
Please test the current svn. Just remove gtkdoc-rebase temprarily to confirm that it works.

2009-01-07  Stefan Kost  <ensonic@users.sf.net>

	* gtk-doc.m4:
	* gtk-doc.make:
	* gtk-doc.notmpl.make:
	  Detect gtkdoc-rebase in gtk-doc.m4. Based on idea of Sven Herzberg.
	  Fixes #562310
Comment 9 Stefan Sauer (gstreamer, gtkdoc dev) 2009-01-21 13:54:04 UTC
Please reopen in case it still causes issues.
Comment 10 Björn Lindqvist 2009-06-06 18:28:14 UTC
I can't see that the problem is fixed. The install-data-local target in gtk-doc.make is ran unconditionally whether --enable-gtk-doc is passed to configure or not. In that target there is this line:

$(GTKDOC_REBASE) --relative --dest-dir=$(DESTDIR) --html-dir=$${installdir};

That line runs if there are gtk-doc generated html-files in the html directory which is the case for distributed tarballs. I don't know what the fix is, but the problem is that gtk-doc.make tries to run gtk-doc commands even when gtk-doc is disabled.
Comment 11 Björn Lindqvist 2009-06-06 19:41:28 UTC
The first time I ran the build the GTKDOC_REBASE was set to the empty string which made the above command fail.. But now that I've tried some more it seems that the variable is always set to GTKDOC_REBASE = true which makes it builds correctly.  Sorry for the noise.
Comment 12 Norman Khine 2009-06-30 12:39:37 UTC
Hi,
I still get this problem with glib-2.21.2

[snip]
-- Installing ./html/left.png
-- Installing ./html/mainloop-states.gif
-- Installing ./html/right.png
-- Installing ./html/style.css
-- Installing ./html/tools.html
-- Installing ./html/up.png
/bin/sh: line 1: gtkdoc-rebase: command not found

Is there a work around to get it built on OS X 10.4.11?
Comment 13 Stefan Sauer (gstreamer, gtkdoc dev) 2009-06-30 13:11:29 UTC
Norman, it worn't be fixed for existing tarballs. You could hand-patch the makefile yourself most probably.
Comment 14 OBATA Akio 2009-07-01 23:56:38 UTC
When glib (and other products) will contains the fix?
wait gtk-doc-1.12 release?