Currnet CVS fails to configure

Currnet CVS fails to configure

[Dale P. Smith]

Greetings!

The current CVS guile-gtk fails to configure on my system, basically a
stock Debian Potato intel system, except for CVS guile.  Gtk+ is at 1.2.

I commented out some things in configure.in, as shown in the patch
below.  It now configures and builds just fine.  I'm not sure what's
missing, but I don't think I have any of that xxx_2_0 stuff on my
system.

-Dale


Index: configure.in
===================================================================
RCS file: /cvs/gnome/gnome-guile/guile-gtk/configure.in,v
retrieving revision 1.43
diff -c -r1.43 configure.in
*** configure.in	2000/11/19 22:29:05	1.43
--- configure.in	2000/11/28 17:11:10
***************
*** 15,28 ****
              [  --enable-debug          compile with -g for debugging
symbols],
              [ CFLAGS="-g $CFLAGS" ])
  
! AC_CHECK_PROG(GTK_CONFIG_2_0, gtk-config-2.0, yes, no)
  
! if test $GTK_CONFIG_2_0 = no; then
     AM_PATH_GTK(1.2.0,,AC_ERROR(need at least Gtk+ version 1.2),
gthread)
! else
!    AM_PATH_GTK_2_0(1.3.1,,AC_ERROR(need at least Gtk+ version 1.3.1),
gthread)   
!    AC_DEFINE(GTK_2_0)
! fi
  
  # XXX - gtk_config_*_version leaks from AM_PATH_GTK.
  
--- 15,28 ----
              [  --enable-debug          compile with -g for debugging
symbols],
              [ CFLAGS="-g $CFLAGS" ])
  
! dnl AC_CHECK_PROG(GTK_CONFIG_2_0, gtk-config-2.0, yes, no)
  
! dnl if test $GTK_CONFIG_2_0 = no; then
     AM_PATH_GTK(1.2.0,,AC_ERROR(need at least Gtk+ version 1.2),
gthread)
! dnl else
! dnl   AM_PATH_GTK_2_0(1.3.1,,AC_ERROR(need at least Gtk+ version
1.3.1), gthread)   
! dnl    AC_DEFINE(GTK_2_0)
! dnl fi
  
  # XXX - gtk_config_*_version leaks from AM_PATH_GTK.
  

-- 
Dale P. Smith
Altus Technologies Corp.
dsmith@altustech.com
440-746-9000 x309

Re: Currnet CVS fails to configure

[Marius Vollmer]

"Dale P. Smith" <dpsm@en.com> writes:

> The current CVS guile-gtk fails to configure on my system, basically a
> stock Debian Potato intel system, except for CVS guile.  Gtk+ is at 1.2.

What error messages do you get?  If possible, we'd like to fix your
problem without just removing the offending bits.

Re: Currnet CVS fails to configure

[Ariel Rios]

On 28 Nov 2000, Marius Vollmer wrote:
> What error messages do you get?  If possible, we'd like to fix your
> problem without just removing the offending bits.
Exactly, unfortunately I have Gtk CVS HEAD in my machine so
I might not be getting that error

ariel 

Re: Currnet CVS fails to configure

[Marius Vollmer]

Ariel Rios <ariel@arcavia.com> writes:

> On 28 Nov 2000, Marius Vollmer wrote:
> > What error messages do you get?  If possible, we'd like to fix your
> > problem without just removing the offending bits.
>
> Exactly, unfortunately I have Gtk CVS HEAD in my machine so
> I might not be getting that error

I have a regular gtk+ 1.2.something installed (from Debian unstable),
so between the two of us, we should be able to sort this out.

Re: Currnet CVS fails to configure

[Dale P. Smith]

Marius Vollmer wrote:
> 
> Ariel Rios <ariel@arcavia.com> writes:
> 
> > On 28 Nov 2000, Marius Vollmer wrote:
> > > What error messages do you get?  If possible, we'd like to fix your
> > > problem without just removing the offending bits.
> >
> > Exactly, unfortunately I have Gtk CVS HEAD in my machine so
> > I might not be getting that error
> 
> I have a regular gtk+ 1.2.something installed (from Debian unstable),
> so between the two of us, we should be able to sort this out.

Looks like AM_PATH_GTK_2_0 isn't defined anywhere, while AM_PATH_GTK is
defined in aclocal.m4.

-Dale
-- 
Dale P. Smith
Altus Technologies Corp.
dsmith@altustech.com
440-746-9000 x309

Re: Currnet CVS fails to configure

[Greg Troxel]

I am pretty sure I had this problem too, and commented it out.
I think the problem may be that the gtk.m4 that comes with gtk 1.2
defines only AM_PATH_GTK, and not AM_PATH_GTK_2_0.  So we either need
to avoid using it, to avoid using it (so that configure runs) if 2.0
is not installed, or to include the .m4 source in acinclude.m4.
But aclocal may choke if it is multiply defined.
I think the hard lesson here is that automake/aclocal is not forgiving
of interface changes in programs' .m4 files.

Of course, one can require having up-to-date stuff if one is using
CVS, but this seems unfortunate.  I wonder if there is some way to put
in configure.in a test to avoid evaling the transformed output 
of AM_PATH_GTK_2_0 if it does not get transformed, like

a=AM_PATH
b=GTK_2_0
c=$a_$b # avoid substitution
if [ "AM_PATH_GTK_2_0" != $c ]; then
  AM_PATH_GTK_2_0(blah blah)
else
  echo "warning: AM_PATH_GTK_2_0 not defined by aclocal, continuing
fi

I'd be stunned if this worked (not run), but thought I'd throw out the
idea.


        Greg Troxel <gdt@ir.bbn.com>

Re: Currnet CVS fails to configure

[Dale P. Smith]

Greg Troxel wrote:
> Of course, one can require having up-to-date stuff if one is using
> CVS, but this seems unfortunate.  I wonder if there is some way to put
> in configure.in a test to avoid evaling the transformed output
> of AM_PATH_GTK_2_0 if it does not get transformed, like
> 
> a=AM_PATH
> b=GTK_2_0
> c=$a_$b # avoid substitution
> if [ "AM_PATH_GTK_2_0" != $c ]; then
>   AM_PATH_GTK_2_0(blah blah)
> else
>   echo "warning: AM_PATH_GTK_2_0 not defined by aclocal, continuing
> fi

My m4 is a little rusty, but can't something like
"ifdef([AM_PATH_GTK_2_0], 2_0_stuff, pre_2_0_junk)" be used?

-Dale
-- 
Dale P. Smith
Altus Technologies Corp.
dsmith@altustech.com
440-746-9000 x309

Re: Currnet CVS fails to configure

[Ariel Rios]

> 
> Of course, one can require having up-to-date stuff if one is using
> CVS, but this seems unfortunate.  I wonder if there is some way to put
> in configure.in a test to avoid evaling the transformed output 
> of AM_PATH_GTK_2_0 if it does not get transformed, like
The problem is that even though AM_PATH_GTK_2_0 is not evaluated,
at the time that ./autogen.sh is run it complains about not finding it.

ariel

Re: Currnet CVS fails to configure

[Dale P. Smith]

Greg Troxel wrote:
> I wonder if there is some way to put
> in configure.in a test to avoid evaling the transformed output
> of AM_PATH_GTK_2_0 if it does not get transformed, like
> 
> a=AM_PATH
> b=GTK_2_0
> c=$a_$b # avoid substitution
> if [ "AM_PATH_GTK_2_0" != $c ]; then
>   AM_PATH_GTK_2_0(blah blah)
> else
>   echo "warning: AM_PATH_GTK_2_0 not defined by aclocal, continuing
> fi

This seems to work for me (watch line wrapping):

Index: configure.in
===================================================================
RCS file: /cvs/gnome/gnome-guile/guile-gtk/configure.in,v
retrieving revision 1.43
diff -u -r1.43 configure.in
--- configure.in        2000/11/19 22:29:05     1.43
+++ configure.in        2000/11/29 01:12:29
@@ -20,8 +20,9 @@
 if test $GTK_CONFIG_2_0 = no; then
    AM_PATH_GTK(1.2.0,,AC_ERROR(need at least Gtk+ version 1.2),
gthread)
 else
-   AM_PATH_GTK_2_0(1.3.1,,AC_ERROR(need at least Gtk+ version 1.3.1),
gthread)   
-   AC_DEFINE(GTK_2_0)
+   ifdef([AM_PATH_GTK_2_0],
+      AM_PATH_GTK_2_0(1.3.1,,AC_ERROR(need at least Gtk+ version
1.3.1), gthread)   
+      AC_DEFINE(GTK_2_0))
 fi
 
 # XXX - gtk_config_*_version leaks from AM_PATH_GTK.


A "release" should have configure already created from configure.in, and
should run on any system without m4 and the auto* tools.  The system on
which configure is created needs to have the AM_PATH_GTK_2_0 macro
installed.  The "ifdef" I added is just a convenience for people
building from cvs without gtk 2 installed.

-Dale
-- 
Dale P. Smith
Altus Technologies Corp.
dsmith@altustech.com
440-746-9000 x309

Currnet CVS fails to configure - the patch

[Martin Baulig]

"Dale P. Smith" <dpsm@en.com> writes:

> The current CVS guile-gtk fails to configure on my system, basically a
> stock Debian Potato intel system, except for CVS guile.  Gtk+ is at 1.2.
> 
> I commented out some things in configure.in, as shown in the patch
> below.  It now configures and builds just fine.  I'm not sure what's
> missing, but I don't think I have any of that xxx_2_0 stuff on my
> system.

Hi,

this happens because the current check for GTK+ is just broken.

The current check requires you to have both GTK+ 1.2 and 1.3 installed
to make it configure.

Here's a patch which makes it use gnome-common / pkgconfig to check for
stuff and use the conditional GNOME 1.x / 2.x support which I'm using
in gnome-libs HEAD's dependencies.

In the default configuration, the patch defaults to the GNOME 1.x platform
and you need to give configure the --enable-platform-gnome-2 argument to
enable support for GNOME 2.x.

Here it comes:

Re: Currnet CVS fails to configure - the patch

[Ariel Rios]

On 29 Nov 2000, Martin Baulig wrote:

> Here's a patch which makes it use gnome-common / pkgconfig to check for
> stuff and use the conditional GNOME 1.x / 2.x support which I'm using
> in gnome-libs HEAD's dependencies.
I suppose this gnome-common thingie is safe enough to be used right now
and it won't break anything. (I am completely ignorant of what
gnome-common is)

> In the default configuration, the patch defaults to the GNOME 1.x platform
> and you need to give configure the --enable-platform-gnome-2 argument to
> enable support for GNOME 2.x.
Exactly what we want. I broke things badly when doing the GTK 2.0 update
=(

ariel

Re: Currnet CVS fails to configure - the patch

[Ariel Rios]

On 29 Nov 2000, Martin Baulig wrote:

> Here's a patch which makes it use gnome-common / pkgconfig to check for
> stuff and use the conditional GNOME 1.x / 2.x support which I'm using
> in gnome-libs HEAD's dependencies.
Looking at your patch, it seems that the gnome-common stuff removes
the dependencies on the macros dir. Is that right?
The patch looks good to me. Unless Marius has any objection, please
apply it.

ariel

Re: Currnet CVS fails to configure - the patch

[Martin Baulig]

Ariel Rios <ariel@arcavia.com> writes:

> On 29 Nov 2000, Martin Baulig wrote:
> 
> > Here's a patch which makes it use gnome-common / pkgconfig to check for
> > stuff and use the conditional GNOME 1.x / 2.x support which I'm using
> > in gnome-libs HEAD's dependencies.

> Looking at your patch, it seems that the gnome-common stuff removes
> the dependencies on the macros dir. Is that right?

Yes, it also removes the macros dir and thus makes the tarball ~240 kB
smaller ....

> The patch looks good to me. Unless Marius has any objection, please
> apply it.

Cool, but I think I need to wait until Martijn made a new pkg-config release,
I found a bug in it which makes the GTK+ check fail after I made the patch.

-- 
Martin Baulig
martin@gnome.org (private)
baulig@suse.de (work)

Re: Currnet CVS fails to configure - the patch

[Ariel Rios]

> Yes, it also removes the macros dir and thus makes the tarball ~240 kB
> smaller ....
I yesterday ran make distcheck on my CVS tree and the size of the
tarball is 592140... So it means that with this change, 
the new tarball will be of about 350Kb! Wow!
  
ariel

Re: Currnet CVS fails to configure - the patch

[Martin Baulig]

Ariel Rios <ariel@arcavia.com> writes:

> > Yes, it also removes the macros dir and thus makes the tarball ~240 kB
> > smaller ....

> I yesterday ran make distcheck on my CVS tree and the size of the
> tarball is 592140... So it means that with this change, 
> the new tarball will be of about 350Kb! Wow!

Not really (macros are good compressable, 240 kB is their uncompressed size):

-rw-r--r--    1 martin   martin     554848 Nov 29 22:51 gnome-guile-0.20pre.tar.gz

But the difference will be larger on CVS checkouts.

-- 
Martin Baulig
martin@gnome.org (private)
baulig@suse.de (work)

Re: Currnet CVS fails to configure - the patch

[Martin Baulig]

Ariel Rios <ariel@arcavia.com> writes:

> > Yes, it also removes the macros dir and thus makes the tarball ~240 kB
> > smaller ....

Ok, just committed all this stuff ....

After that, I run a distcheck over a freshly checked out guile-gtk and a
freshly checked out gnome-guile on the GNOME 1.x platform and this both
worked fine :-)

-- 
Martin Baulig
martin@gnome.org (private)
baulig@suse.de (work)

Re: Currnet CVS fails to configure - the patch

[Marius Vollmer]

Ariel Rios <ariel@arcavia.com> writes:

> The patch looks good to me. Unless Marius has any objection, please
> apply it.

You guys are handling this much faster than I could follow you, so
please just go ahead and do whatever you two think is Right.  I'll
complain later... ;-)

Re: Currnet CVS fails to configure - the patch

[Lars J. Aas]

On Wed, Nov 29, 2000 at 12:42:04AM +0100, Martin Baulig wrote:
: Here's a patch which makes it use gnome-common / pkgconfig to check for
: stuff and use the conditional GNOME 1.x / 2.x support which I'm using
: in gnome-libs HEAD's dependencies.

Does this mean that guile-gtk will depend on having installed GNOME on
your build system?

  Lars J

Re: Currnet CVS fails to configure - the patch

[Martin Baulig]

"Lars J. Aas" <larsa@sim.no> writes:

> On Wed, Nov 29, 2000 at 12:42:04AM +0100, Martin Baulig wrote:
> : Here's a patch which makes it use gnome-common / pkgconfig to check for
> : stuff and use the conditional GNOME 1.x / 2.x support which I'm using
> : in gnome-libs HEAD's dependencies.
> 
> Does this mean that guile-gtk will depend on having installed GNOME on
> your build system?

No, it only means that you need to have gnome-common and pkg-config on
your build system (both of them don't have any additional dependencies).

-- 
Martin Baulig
martin@gnome.org (private)
baulig@suse.de (work)

Re: Currnet CVS fails to configure - the patch

[Ariel Rios]

On 29 Nov 2000, Martin Baulig wrote:
I'm getting the following doing ./autogen.sh
Any clue?

ariel

(cached) (cached) checking for pkg-config... /usr/local/bin/pkg-config
checking for pkg-config... yes
checking for GNOME Platform... GNOME 1.x
checking for libraries... gtk+ (gthread)
configure: error: Package gthread was not found in the pkg-config search
path.
Perhaps you should add the directory containing `gthread.pc'
to the PKG_CONFIG_PATH environment variable
Unknown package 'gthread'
configure: error: ./configure failed for guile-gtk

Re: Currnet CVS fails to configure - the patch

[Martin Baulig]

Ariel Rios <ariel@arcavia.com> writes:

> On 29 Nov 2000, Martin Baulig wrote:
> I'm getting the following doing ./autogen.sh
> Any clue?

Yes, there was a problem with the *.pc files in glib and GTK+. I fixed this
in CVS, but AFAIK there wasn't a new release since that so that you need to
grab them from CVS.

> (cached) (cached) checking for pkg-config... /usr/local/bin/pkg-config
> checking for pkg-config... yes
> checking for GNOME Platform... GNOME 1.x
> checking for libraries... gtk+ (gthread)
> configure: error: Package gthread was not found in the pkg-config search
> path.
> Perhaps you should add the directory containing `gthread.pc'
> to the PKG_CONFIG_PATH environment variable
> Unknown package 'gthread'
> configure: error: ./configure failed for guile-gtk
> 

-- 
Martin Baulig
martin@gnome.org (private)
baulig@suse.de (work)

Re: Currnet CVS fails to configure - the patch

[Ariel Rios]

On 3 Dec 2000, Martin Baulig wrote:

> Yes, there was a problem with the *.pc files in glib and GTK+. I fixed this
> in CVS, but AFAIK there wasn't a new release since that so that you need to
> grab them from CVS.
Oops! That's a big problem! I was intending to do a dual
gnome-guile / guile-gtk release in the next week... I cannot release until
there is a new Gtk release (which I dunno if will happen soon)

ariel

Re: Currnet CVS fails to configure - the patch

[Marius Vollmer]

Ariel Rios <ariel@arcavia.com> writes:

> On 3 Dec 2000, Martin Baulig wrote:
> 
> > Yes, there was a problem with the *.pc files in glib and GTK+. I fixed this
> > in CVS, but AFAIK there wasn't a new release since that so that you need to
> > grab them from CVS.
>
> Oops! That's a big problem! I was intending to do a dual
> gnome-guile / guile-gtk release in the next week... I cannot release until
> there is a new Gtk release (which I dunno if will happen soon)

Has this been resolved?

I think the configuration of guile-gtk is getting too complicated.  We
can't depend on unreleased versions of Gtk+ just to get the
complicated Gnome configure machine satisfied.

If we need all this complexity for Gtk 2.0, we should make a branch
for this in guile-gtk.

Re: Currnet CVS fails to configure - the patch

[Ariel Rios]

> If we need all this complexity for Gtk 2.0, we should make a branch
> for this in guile-gtk.
We depende on a new Gtk 1.2 release but I am starting to wonder if 
Owen / Havoc will ever do one.

Martin, any thoughts?

ariel

Re: Currnet CVS fails to configure - the patch

[Marius Vollmer]

Ariel Rios <ariel@arcavia.com> writes:

> > If we need all this complexity for Gtk 2.0, we should make a
> > branch for this in guile-gtk.
>
> We depende on a new Gtk 1.2 release but I am starting to wonder if
> Owen / Havoc will ever do one.

Ok, we need to make some progress on this.

There are two issues: generating the build scripts from their sources
(i.e. configure.in -> configure), and running the build scripts from a
tar ball (i.e. running configure).  Let's call the people who do the
first thing `developers', and the rest `users'.

The ideal thing would be to have a single guile-gtk package for all
versions of Gtk+.  We should try hard to achieve this.  (That is, no
branch.)

It is OK when developers need to get extra stuff like gnome-common and
pkg-config even if they are not using Gtk+2.  It is not OK that users
need these packages if they are not using Gtk+2.

Right now, it is more important that guile-gtk works for the 1.2.x
branch of Gtk+ than that it works for the upcoming 2.0.  So the first
thing we need to do is to make sure that the generated configure
script runs on a system that does not have gnome-common or pkg-config
or glib.pc, etc.

Essentially, configure should be reverted to its old behaviour when
pkg-config is not found, and just use gtk-config.


Is this OK with everyone?