Re: build problems

[John Darrington]

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 alpha.gnu.org ?

     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 
gnulib
       warnings), however the output clearly shows the alternative to requiring 
a
       whole version bump of gettext is to edit po/Makevars. Essentially, some 
gnulib
       modules have requirements for po/Makevars that they can append 
automatically
       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 configure.ac):
       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 
tool.
       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:
              data-editor.c
              text-data-import-dialog.c
              text-data-import-dialog.h
     
            Uses a GtkAssistant (new in 2.10). Fix is to make compiling
            text-data-import-dialog conditional on gtk-2.10 (automake.mk) and 
the
            single call out from data editor condiitonally compiled.
     
       (ii) tooltips in the treeview
             Files affected:
              dict-display.c
     
            Uses GtkTooltip rather than the old GtkTooltips (new in 2.12). Fix 
is
            to make the affected method and its caller conditionally
            compiled.

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 
disabled)])])
     +  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 
disabled)])])
     +  PKG_CHECK_MODULES(GTK, gtk+-2.0 >= 2.8.0,,
     +    [PSPP_REQUIRED_PREREQ([gtk+ 2.0 v2.8.0 or later (or use 
--without-gui)])])
        PKG_CHECK_MODULES(GLADE, libglade-2.0 >= 2.6.0,,
          [PSPP_REQUIRED_PREREQ([libglade 2.0 v2.6.0 or later (or use 
--without-gui)])])
      fi
      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
http://library.gnome.org/devel/gtk/stable/gtk-Feature-Test-Macros.html 


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
http://savannah.gnu.org/patch/?group=pspp if that's easier for you.

J'


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

signature.asc
Description: Digital signature