From: Rob Browning <rlb@defaultvalue.org>
Subject: Re: compilation warnings
Date: Wed, 24 Sep 2003 01:11:22 -0500 [thread overview]
Message-ID: <87ad8uogvp.fsf@raven.i.defaultvalue.org> (raw)
In-Reply-To: <m3wubz4gup.fsf@multivac.cwru.edu> (Paul Jarc's message of "Tue, 23 Sep 2003 12:19:36 -0400")
prj@po.cwru.edu (Paul Jarc) writes:
> That's not especially useful advice, though. After a new autoconf
> release, Guile won't be updated instantly; it'll take some time.
> Maybe a significant amount of time in pathological cases, but in any
> case, how will we know?
Depends on what you mean. Distribution .tar.gzs (of course) aren't
supposed to require any of the autotools, but if you're building from
CVS, then we reserve the right to require the latest versions.
However, at any given time, we probably only require some fairly
recent version.
Right now I'm using automake 1.7.7 and autoconf 2.57. so whenever I'm
working on unstable, I'll be making sure we're compatible with that.
(Just tested an ./autogen.sh on unstable, and it seems OK...)
If you mean how would someone who wants to work on a 1.6.X tarfile
know which autotools to use, then that's tougher. Right now we just
supply a list of versions known not to work in HACKING. Ideally,
they'd just be able to use the latest tools as well. Frankly, I'd
consider a failure to build using the latest autotools important
enough to warrant a stable point release.
> Also, which tools do we need? Guile has its own libtool, right? So
> just autoconf and automake?
You actually do need autoconf, automake, and libtool. We have our own
version of ltdl, but you'll still need libtool for all the rest:
compilation, etc. (or more specifically, so ./autogen.sh can run
libtoolize).
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
next prev parent reply other threads:[~2003-09-24 6:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-04 4:36 compilation warnings Paul Jarc
2003-07-27 16:56 ` Marius Vollmer
2003-07-28 22:37 ` Kevin Ryde
2003-09-22 21:58 ` Paul Jarc
2003-09-23 4:22 ` Rob Browning
2003-09-23 16:19 ` Paul Jarc
2003-09-24 6:11 ` Rob Browning [this message]
2003-10-07 16:00 ` 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
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ad8uogvp.fsf@raven.i.defaultvalue.org \
--to=rlb@defaultvalue.org \
/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).