Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
From: "Ralf Habacker" <Ralf DOT Habacker AT freenet DOT de>
To: "Cygwin" <cygwin AT sources DOT redhat DOT com>
Subject: RE: Cygwin Autotool Wrappers
Date: Wed, 23 Jan 2002 07:41:56 +0100
Message-ID: <00ad01c1a3d9$0d443890$60a407d5@BRAMSCHE>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <3C4DAA41.10607@ece.gatech.edu>
Importance: Normal

> -----Original Message-----
> From: cygwin-owner AT cygwin DOT com [mailto:cygwin-owner AT cygwin DOT com]On Behalf
> Of Charles Wilson
> Sent: Tuesday, January 22, 2002 7:07 PM
> To: Parker, Ron
> Cc: cygwin AT cygwin DOT com
> Subject: Re: Cygwin Autotool Wrappers
>
>
> Parker, Ron wrote:
>
> > There is a problem IMO with the autotool wrappers. If I configure in a
> > directory other than the source directory, most configure scripts will fail
> > to find aclocal, autoconf, automake and autoheader utilities. This normally
> > isn't a problem, but I have run into some packages that really do want to
> > re-auto* themselves.
>
>
> Known problem, and described in the READMEs.  Workarounds: copy
> configure.in into your build dir, create a dummy configure.in in your
> build dir that merely has AC_REQUIRE(2.xx), or set PATH to avoid the
> wrappers entirely.  In the first two cases, the configure.in will ONLY
> be used by the wrappers and will not affect the re-auto process.
>
>
> > The issue is that configure attempts a "auto* --version" to determine if the
> > tool exists, because there is no configure.{in,ac} in the build directory it
> > fails. My thought was to patch the tools to either return the stable or
> > devel version number in this case. Configure doesn't really care about the
> > number, just the success of the operation.
>
>
> Right, but I'm unsure about the "correct" answer to the following...
>
>
> > Before embarking on patching the autotool wrappers, I was wondering if you
> > would be open to a patch for them and which version number you would prefer
> > they return.
>
>
> Actually, I already HAVE a patch for this behavior -- but I'm not sure
> which of the following is "correct"
>    a) status quo
>    b) return STABLE version
>    c) return DEVEL version
>
Could this not be switched over a environment var ?
What about the wrappers should print a line like this ...
$ aclocal | autoscan | ...
 "note: .... uses currently autoconf 2.5 compatibility mode. Set export XYZ=2.13 (or something else ) to switch to
2.13 compatibility" ...

and let the user choose which mode he like ?

> > I already have a release on file with Red Hat for contributions
> > to the cygwin.
>
> Not necessary in any case -- the wrappers are not part of cygwin itself.
>
>
> I've copied this message to the cygwin mailing list, in hopes of
> gathering some opinions...Note that Robert Collins has already mentioned
> the "autoscan" case (quoted here for completeness) -- but his response
> doesn't address the "configuing-outside-of-srcdir" problem you mention:
>
See above
>
> > There is a problem that isn't addressed: autoscan.
> >
> > Whatever heuristic is appropriate for autoscan should equally apply to
> > an empty directory.
> >
> > I can't think of an appropriate heuristic, but your message
> > "autoscan: Couldn't find configure.ac nor configure.in file
> > run /usr/auto*/bin/autoscan directly"
> > seems reasonable to me. (That is, that the user must explicity choose in
> > this case).
>
> I *really* don't know what the right answer is, here...perhaps (in empty
> directory)
>
>    aclocal --version: report DEVEL
>    automake --version: report DEVEL
>    autoconf --version: report DEVEL
>    autoheader --version: report DEVEL
>
See above
>
> because these four are often checked by configure scripts, and are
> sometimes (re)used by automated build procedures outside of the "real"
> srcdir.
>
>    autoheader --version: status quo
>    autoscan --version: status quo
>    autoupdate --version: status quo
>    ifnames --version: status quo
>    libtool --version: stutus quo
>    libtoolize --version: status quo
>
> because none of these should ever be caused by automated build
> procedures outside of the "real" srcdir.  These are all tools that are
> invoked by hand when maintaining / autoconfiscating a package.
> (/usr/bin/libtool is not typically called during builds.  libtoolized
> packages create their OWN local copy of libtool during configure, and
> use that)
>
> Anybody else want to chime in on this topic?
>
> --Chuck
>
>
>
>
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
>
>


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/