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
> 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:
> 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
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/
