Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@sources.redhat.com Delivered-To: mailing list cygwin@sources.redhat.com To: Charles Wilson Cc: Ronald Landheer , cygwin@cygwin.com Subject: Re: Automake 1.5 References: <3B9BFF80.9020504@ece.gatech.edu> From: James Youngman Date: 10 Sep 2001 18:27:19 +0100 In-Reply-To: <3B9BFF80.9020504@ece.gatech.edu> Message-ID: Lines: 56 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Charles Wilson writes: > James Youngman wrote: > > > >>Thus, Automake 1.5 broke my bootstrap script and does not allow me > >>to compile Eleanor without problems any more. My questions are: > >> > > I have also had to downgrade this stuff, becuase the latest version > > of > > autoconf insists on using config.sub even if all you want to do is > > figure out the value of EXEHDR. Previous versions of autoconf didn't > > require that. The problem is that the current version of automake > > doesn't know to include config.sub even though autoconf needs it :-( > > > Okay, I'd like for somebody to explain this to me. [...] > Now, in both cases there are a few backwards-incompatibilities. Thus, > projects that use the autotools will require some changes in order to > work with the new versions. So why is the first response always to > downgrade back to the old, obsolete versions of the autotools -- > instead of patching the project to use the new autotools (or better, > patching the project with compatibility macros to support both 2.13 > and 2.52(autoconf)) > > I even submitted patches for libiberty to support both versions, but > it was more or less ignored. It seems the response was "we're > sticking with 2.13" > > What? Forever? > > I don't understand. Help me? The problem (for me) is not that I refuse to upgrade to either; it's that the two versions are _incompatible_; automake is supposed to supply those dependencies that it produces (e.g. install-sh, missing, etc.) and that autoconf produces (e.g. config.sub). It's that with these two particular versions, a particular autoconf macro now requires a file which automake usually does provide, but automake doesn't know about the dependency. This means that for me, there is a temporary workaround of not upgrading to the latest version of autoconf until automake catches up with the new situation. So, I'm not _permanently_ refusing to upgrade; I'm just deferring an upgrade to autoconf until I can upgrade automake to a version that's compatible. -- James Youngman Manchester, UK. +44 161 226 7339 PGP (GPG) key ID for is 64A95EE5 (F1B83152). -- 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/