This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 into your build dir, create a dummy 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 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 nor 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 

   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" 

   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?


Unsubscribe info:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]