[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: build problems

From: John Darrington
Subject: Re: build problems
Date: Mon, 26 May 2008 08:49:28 +0800
User-agent: Mutt/1.5.13 (2006-08-11)

On Mon, May 26, 2008 at 12:05:54AM +0100, Ed wrote:
     Debian ships gnulib in /usr/bin and /usr/share/gnulib/. The version is
     too old to supply some of the macros pspp uses, but just pulling the
     git repository (as suggested by the build docs) works just fine.
Is there any particular reason why you're building from CVS rather
than from the pre-release tarball on ?

     I spent a few hours playing with PSPP trying to get it to compile on
     debian/etch. My basic constraint is that while I would like to
     contribute, I simply can't risk the stability of my machine at this
     point, so it has to stay within the confines of debian stable.
     The following are the problems I had.
     (1) gettext-0.17
     - seems to be required so that AM_XGETTEXT_OPTIONS is available (to avoid 
       warnings), however the output clearly shows the alternative to requiring 
       whole version bump of gettext is to edit po/Makevars. Essentially, some 
       modules have requirements for po/Makevars that they can append 
       if AM_XGETTEXT_OPTIONS is available, otherwise this edit is required.

My recollection is that there were two problems.  Editing po/Makevars
only solved one of them.  Unfortunately I don't remember the exact details.

     (2) gperf
     - despite the immense configure process, gperf isn't tested for (you get 
to make
       and it dies)
     Can easily fix with (in
       AC_CHECK_PROG([have_gperf], [gperf], [yes], [no])
       AS_IF([test x$have_gperf = xno], [AC_MSG_ERROR([gperf is required!])])
       but this then requires the user running a configure script to have the 
       The force of my magic is insufficient for this task.

This is wrong.  Building from the tarball doesn't require gperf.  It's
only required when building from a CVS checkout.  Therefore, testing
for it in configure is incorrect.

     (3) gtk+-2.12
       There are only two places where post 2.8 APIs are used:
       ( i) the data import wizard
            Files affected:
            Uses a GtkAssistant (new in 2.10). Fix is to make compiling
            text-data-import-dialog conditional on gtk-2.10 ( and 
            single call out from data editor condiitonally compiled.
       (ii) tooltips in the treeview
             Files affected:
            Uses GtkTooltip rather than the old GtkTooltips (new in 2.12). Fix 
            to make the affected method and its caller conditionally

This analysis is correct.  However, feedback from users indicated the
absence of the tooltips functions, was a serious impediment to the
useability of the gui.  The problem is that earlier Gtk versions don't
allow tooltips to be specified for individual rows of treeview widgets.

My opinion is that inserting patches just to make the code compatible
with old versions of libraries is a counterproductive process.
Perhaps however we could publish your patches as seperate items for
people who really want to build against old libraries.  But this is a
decision for Ben, who is the pspp maintainer.  

      if test x"$with_gui" != x"no" ; then 
     +  PKG_CHECK_MODULES(GTK, gtk+-2.0 >= 2.12.0, [have_gtk_2_12_0=yes],
     +    [PSPP_OPTIONAL_PREREQ([gtk+ 2.0 v2.12.0 or later (some features 
     +  PKG_CHECK_MODULES(GTK, gtk+-2.0 >= 2.10.0,  [have_gtk_2_10_0=yes],
     +    [PSPP_OPTIONAL_PREREQ([gtk+ 2.0 v2.10.0 or later (some features 
     +  PKG_CHECK_MODULES(GTK, gtk+-2.0 >= 2.8.0,,
     +    [PSPP_REQUIRED_PREREQ([gtk+ 2.0 v2.8.0 or later (or use 
        PKG_CHECK_MODULES(GLADE, libglade-2.0 >= 2.6.0,,
          [PSPP_REQUIRED_PREREQ([libglade 2.0 v2.6.0 or later (or use 
      AM_CONDITIONAL(WITHGUI, test x"$with_gui" != x"no")
     +AS_IF([test x"$have_gtk_2_10_0" = x"yes"], 
     +      [AC_DEFINE(PSPP_WITH_GTK_2_10_0, 1, 
     +                 [Define to 1 if GTK+-2.0 2.10.0+ is available.])])
     +AM_CONDITIONAL(PSPP_WITH_GTK_2_10_0, test x"$have_gtk_2_10_0" = x"yes")
     +AS_IF([test x"$have_gtk_2_12_0" = x"yes"], 
     +      [AC_DEFINE(PSPP_WITH_GTK_2_12_0, 1,
     +                 [Define to 1 if GTK+-2.0 2.12.0+ is available.])])
     +AM_CONDITIONAL(PSPP_WITH_GTK_2_12_0, test x"$have_gtk_2_12_0" = x"yes")

This is overly complex.  You don't need these conditionals.  Instead of 
#ifndef PSPP_WITH_GTK_2_10_0, you can simply use the GTK_CHECK_VERSION
macro.  See 

Maybe it'll be easier for Ben to make a decision, if you provide each
point that you've changed in a seperate patch.  You can submit them at if that's easier for you.


PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See or any PGP keyserver for public key.

Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]