[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: subdir-object compatibility Autotests [libtool--devo--1.0--patch-260
From: |
Gary V. Vaughan |
Subject: |
Re: subdir-object compatibility Autotests [libtool--devo--1.0--patch-260] |
Date: |
Fri, 15 Oct 2004 18:44:15 +0100 |
User-agent: |
Mozilla Thunderbird 0.8 (Macintosh/20040913) |
Bob Friesenhahn wrote:
On Thu, 14 Oct 2004, Gary V. Vaughan wrote:
The good news is that Autoconf and Automake do install properly under
MinGW/Cygwin. Sooner or later we will encounter a target where this
is not feasable or the effort is otherwise prohibitive. Should we
worry about that?
I'm not sure what you mean. Please explain.
I mean a build environment with a bare-bones toolset which is sufficient
to run configure but lacks enough support (e.g. Perl, m4) to properly
support Autoconf and Automake. In this case, Autoconf/Automake are
executed on a more capable system to prepare the package (a
cross-development model). Since libtool is clearly moving more toward
using m4, it seems that m4 will be a clear requirement.
The barebones toolset must continue to be enough to install a libtool
tarball. The m4sh scripts (I assume that is the m4 requirement you
mention) are expanded to .in files for distribution with configure, so
the installer doesn't need autom4te installed.
The other issue is my proposal to change to an Autotest test suite by
the time we release 2.2. That is certainly more contentious, because
the package installer will indeed need autoconf (not necessarily an
autotest bearing version) and automake. My rationale is that the lack
of these tools doesn't (and mustn't) affect the installers ability to
build libtool from a release tarball and install it on her machine.
Additionally I consider it a positive *improvement* in the libtool
testsuite that it will be tested against the installers autoconf and
automake rather than the tools of whoever rolled the release.
Before we can consider the autotest migration to be mature I would
expect make check to continue to work (without failed tests) when
autoconf and automake are not installed on the testers machine, and to
simply skip any tests which rely on those tools. Rerunning skipped
tests verbosely will give a reason a la: `this test requires an
installed autoconf on $PATH'.
This is all speculative since thus far all target environments I have
encountered can support Autoconf and Automake.
I consider it important that libtool continues to be useful even without
autoconf and automake, and indeed what point is there running many long
winded tests built by the release manager against his autotools when the
installer just wants to use libtool standalone (say, on a machine that
doesn't have perl).
Cheers,
Gary.
--
Gary V. Vaughan ())_. address@hidden,gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/libtool
Technical Author `(_~)_ http://sources.redhat.com/autobook
signature.asc
Description: OpenPGP digital signature