public inbox for guile-gtk@sourceware.org
 help / color / mirror / Atom feed
From: Greg Troxel <gdt@fnord.ir.bbn.com>
To: "Dale P. Smith" <dpsm@en.com>
Cc: Marius Vollmer <mvo@zagadka.ping.de>,
	Ariel Rios <ariel@arcavia.com>,
	guile-gtk@sourceware.cygnus.com
Subject: Re: Currnet CVS fails to configure
Date: Tue, 28 Nov 2000 15:31:00 -0000	[thread overview]
Message-ID: <rmi7l5n4qsq.fsf@fnord.ir.bbn.com> (raw)
In-Reply-To: <3A243B16.2050E61C@en.com>

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>

  reply	other threads:[~2000-11-28 15:31 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-11-28  9:17 Dale P. Smith
2000-11-28 11:47 ` Marius Vollmer
2000-11-28 14:09   ` Ariel Rios
2000-11-28 15:02     ` Marius Vollmer
2000-11-28 15:12       ` Dale P. Smith
2000-11-28 15:31         ` Greg Troxel [this message]
2000-11-28 16:39           ` Dale P. Smith
2000-11-28 17:54           ` Ariel Rios
2000-11-29  5:29           ` Dale P. Smith
2000-11-28 15:40 ` Currnet CVS fails to configure - the patch Martin Baulig
2000-11-28 21:59   ` Ariel Rios
2000-11-28 22:27   ` Ariel Rios
2000-11-29  2:37     ` Martin Baulig
2000-11-29 10:39       ` Ariel Rios
2000-11-29 13:56         ` Martin Baulig
2000-11-29 14:54         ` Martin Baulig
2000-11-30 16:24     ` Marius Vollmer
2000-11-29  5:22   ` Lars J. Aas
2000-11-29  5:31     ` Martin Baulig
2000-12-02 22:12       ` Ariel Rios
2000-12-03  8:52         ` Martin Baulig
2000-12-03 20:32           ` Ariel Rios
2001-01-06 10:46             ` Marius Vollmer
2001-01-06 15:53               ` Ariel Rios
2001-01-13  4:10                 ` Marius Vollmer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=rmi7l5n4qsq.fsf@fnord.ir.bbn.com \
    --to=gdt@fnord.ir.bbn.com \
    --cc=ariel@arcavia.com \
    --cc=dpsm@en.com \
    --cc=guile-gtk@sourceware.cygnus.com \
    --cc=mvo@zagadka.ping.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).