Mail Archives: cygwin/2002/01/23/01:44:58
> -----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/
- Raw text -