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 510651 - Fix for 501066 broken when gtk-doc not installed`
Fix for 501066 broken when gtk-doc not installed`
Status: RESOLVED DUPLICATE of bug 508897
Product: gtk-doc
Classification: Platform
Component: general
1.10
Other All
: Normal normal
: ---
Assigned To: gtk-doc maintainers
gtk-doc maintainers
Depends on:
Blocks:
 
 
Reported: 2008-01-19 17:57 UTC by Dan Nicholson
Modified: 2008-01-22 13:55 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Use a non-failing check for gtkdoc-rebase (519 bytes, patch)
2008-01-19 17:58 UTC, Dan Nicholson
none Details | Review

Description Dan Nicholson 2008-01-19 17:57:03 UTC
The fix for #501066 (commit 527) is broken when gtkdoc-rebase is not installed.

http://svn.gnome.org/viewvc/gtk-doc?view=revision&revision=527

The problem is that running `which gtkdoc-rebase && do something with it' will return 1 if gtkdoc-rebase is not installed. Since this is the last command run in the shell that make spawns, the process will return 1 and make will fail.

$ sh -c 'which gtkdoc-rebase >/dev/null 2>&1 && gtkdoc-rebase --version'
$ echo $?
1
$ sh -c 'which gtkdoc-rebase >/dev/null 2>&1 && gtkdoc-rebase --version; true'
$ echo $?
0

If you use an `if' statement with no else, though, it will return successfully if the condition isn't met.

$ sh -c 'if which gtkdoc-rebase >/dev/null 2>&1; then echo yes; fi'
$ echo $?
0
Comment 1 Dan Nicholson 2008-01-19 17:58:37 UTC
Created attachment 103213 [details] [review]
Use a non-failing check for gtkdoc-rebase

This changes the check for gtkdoc-rebase to be non-failing. It also suppresses the errors that `which' will print if it's not installed.
Comment 2 Dan Nicholson 2008-01-19 18:08:18 UTC
I should also mention that you don't need to use `which', and it just adds another build requirement. Since you only want to check for the existence of a utility and not store it's path, you can instead use `type', which all Bourne compatible shells have.

$ type gtkdoc-rebase >/dev/null 2>&1
$ echo $?
1
$ type gcc >/dev/null 2>&1
$ echo $?
0
Comment 3 Stefan Sauer (gstreamer, gtkdoc dev) 2008-01-21 08:11:39 UTC
There was also Bug #509539 regarding this issue. We added a '-' to the whole statement. It was committed on the 17th. Is that fix enough?
Comment 4 Dan Nicholson 2008-01-21 15:20:36 UTC
Yeah, that's probably good enough, although you then ignore real errors from gtkdoc-rebase. I don't know exactly what gtkdoc-rebase does, but it would sort of stink to have the command bomb somewhere and leave you with a broken install.
Comment 5 Stefan Sauer (gstreamer, gtkdoc dev) 2008-01-21 15:42:25 UTC
It rewrites URLs. And it only exits with 0 incase of wrong commandline args.
I'll close it as a duplicate for now. Thanks a lot, still.

*** This bug has been marked as a duplicate of 509539 ***
Comment 6 Dan Nicholson 2008-01-21 16:08:23 UTC
Is it really a duplicate? Bug 509539 seems to have to do with `make dist'. This bug causes problems with `make install', in e-d-s, for example. I don't see how the fix for #509539 could prevent install-data-local from failing.
Comment 7 Stefan Sauer (gstreamer, gtkdoc dev) 2008-01-22 06:55:51 UTC
Lets taken bug #508897 then . sorry, I am a bit overworked.

*** This bug has been marked as a duplicate of 508897 ***
Comment 8 Dan Nicholson 2008-01-22 13:55:11 UTC
Oh, I see. I saw that commit and thought it was working around the setting of the installfiles variable. But reading the comments in bug #508997 makes more sense.

Not the solution I would have chosen since now install-data-local will always be successful even when it fails to do anything, but I guess that's what you want.

Thanks for the quick replies.