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 724739 - Self-test fail: gtkdoc-mkdb misusing perl datatype
Self-test fail: gtkdoc-mkdb misusing perl datatype
Status: RESOLVED FIXED
Product: gtk-doc
Classification: Platform
Component: general
1.20
Other Mac OS
: Normal normal
: 1.21
Assigned To: gtk-doc maintainers
gtk-doc maintainers
Depends on:
Blocks:
 
 
Reported: 2014-02-19 17:25 UTC by Daniel Macks
Modified: 2014-02-20 13:43 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Daniel Macks 2014-02-19 17:25:20 UTC
Building gtk-doc-1.20 on OS X 10.8 (perl is 5.12.4 as supplied by Apple, all other deps via Fink), configure and build had nothing unusual that I saw. But then during 'make check'...



Making check in docs
make[3]: Entering directory `/sw/build.build/gtk-doc-1.20-1/gtk-doc-1.20/tests/gobject/docs'
make  check-local
make[4]: Entering directory `/sw/build.build/gtk-doc-1.20-1/gtk-doc-1.20/tests/gobject/docs'
  DOC   0: Scanning header files
  DOC   0: Introspecting gobjects
  DOC   1.0: Building XML
Type of arg 1 to pop must be array (not hash element) at /sw/build.build/gtk-doc-1.20-1/gtk-doc-1.20/gtkdoc-mkdb line 4743, near "};"
Type of arg 1 to push must be array (not hash element) at /sw/build.build/gtk-doc-1.20-1/gtk-doc-1.20/gtkdoc-mkdb line 4764, near "$line;"

and a ton other similar warnings (10, before the test gave up with "too many errors"). Those two specific lines are:

          my $text = pop $md_block->{"lines"};
          [...]
          push $md_block->{"lines"}, $line;

In both cases (and the others, the code is using a reference to a list (a scalar, the pointer stored $md_block->{"lines"}) in as if it were the list itself (a @variable type).

Does some newer version of perl automatically DWIM and resolve the pointer?
Comment 1 Daniel Macks 2014-02-19 17:30:59 UTC
Indeed, perl5.16.2 does auto-resolve the pointer. I don't have other versions handy to figure out exactly when that feature got added. But it's easy to write it portably rather than figuring out and requiring a higher perlversion. Instead of $arraref use @$arrayref (or @{$arrayref} if the ref itself is a complex expression). For example,

-          my $text = pop $md_block->{"lines"};
+          my $text = pop @{$md_block->{"lines"}};

and

-          push $md_block->{"lines"}, $line;
+          push @{$md_block->{"lines"}}, $line;
Comment 2 Daniel Macks 2014-02-19 18:00:27 UTC
One-liner to fix it:

perl -pi -e 's/(push|pop) (\$\w*block->\{"lines"\})/\1 \@\{\2\}/g' gtkdoc-mkdb.in

catches all 12 of them, and now the self-test passes.
Comment 3 Stefan Sauer (gstreamer, gtkdoc dev) 2014-02-19 18:28:32 UTC
Thanks for figuring this out. What can we do to get things tested on macosx *before* we release? Alaso are you maintaining the macos port? Can you include a local patch there?
Comment 4 Stefan Sauer (gstreamer, gtkdoc dev) 2014-02-19 18:42:21 UTC
my machine (ubuntu 12.04 lts) has ancient perl v5.14.2 (from 2011) and it works there too.

commit 685d03c624c3e5184198e191ac52b77d9b41c0bb
Author: Daniel Macks <dmacks@netspace.org>
Date:   Wed Feb 19 19:36:38 2014 +0100

    mkdb: deref the array to not rely on new perl versions
    
    The previous code works in 5.14.2, but apparently not in 5.12.4.
    Fixes #724739
Comment 5 Daniel Macks 2014-02-20 13:43:26 UTC
(sorry again about not including the actual patch).

I'm the maintainer of gtk-doc for Fink. The source package description format is similar to .spec or debian and can include and apply patchfiles and/or execute script blocks in any language.

I run OS X 10.7 and 10.8 machines myself and beg testing favors from someone with 10.9. Fink's glib itself is currently stuck at an old version so I can't test things on top of a modern glib/gtk/GNOME stack (and therefore don't always look at current upstream development of many of my packages), but can certainly try to handle requests by email (or IRC, in #fink on freenode)