From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4415 invoked by alias); 5 Jan 2009 07:05:09 -0000 Received: (qmail 4400 invoked by uid 22791); 5 Jan 2009 07:05:07 -0000 X-SWARE-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL,BAYES_05,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: sourceware.org Received: from out2.smtp.messagingengine.com (HELO out2.smtp.messagingengine.com) (66.111.4.26) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 05 Jan 2009 07:05:02 +0000 Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id EB894201BA5 for ; Mon, 5 Jan 2009 02:04:58 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Mon, 05 Jan 2009 02:04:58 -0500 Received: from [192.168.1.3] (user-0cej09l.cable.mindspring.com [24.233.129.53]) by mail.messagingengine.com (Postfix) with ESMTPSA id 6B0AA3BBDF; Mon, 5 Jan 2009 02:04:58 -0500 (EST) Message-ID: <4961B10E.50708@cwilson.fastmail.fm> Date: Mon, 05 Jan 2009 07:05:00 -0000 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.19) Gecko/20081209 Thunderbird/2.0.0.19 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Mailing List: CygWin-Apps Subject: Re: [ITP] gcc-tools-autoconf, gcc-tools-automake References: <495FBEB4.7020403@cwilson.fastmail.fm> <4961A698.8030805@users.sourceforge.net> In-Reply-To: <4961A698.8030805@users.sourceforge.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com X-SW-Source: 2009-01/txt/msg00007.txt.bz2 Yaakov (Cygwin/X) wrote: > Charles Wilson wrote: >> Special versions of "pristine" (that is, no cygwin-special patches) of >> autoconf-2.59 and automake-1.9.6 as required by gcc, installed into >> /opt/gcc-tools/{bin|lib|share}. > > There's another, *much* simpler way to do this; .cygport attached. And > yes, I would call it autoconf2.59. > > A special automake package is reqlly required as well? Yes, because gcc requires the use of an unmodified automake. Our existing 1.9.6 package is modified [*] -- and you can't have two versions of the same minor automake release installed at the same time in the same prefix. Therefore, automake-1.9.6-pristine has to be installed "somewhere else" -- e.g. not /usr. I take it as given that interoperable autotools must all be installed in the same prefix [**] (can't remember the reasons now, but I learned this the hard way many years ago). So, autoconf-2.59-pristine has to be installed in that same "somewhere else". E.g. not /usr. So, it's not good enough to have /usr/bin/autoconf-2.59 and use the existing /usr/bin/automake-1.9. We have to have new autoconf and automake packages distinct from our existing ones, and they have to be installed "somewhere else". /opt/gcc-tools/ seems reasonable. The "difficulty" you observe is that cygport makes it hard -- and it SHOULD be hard, I'm not pushing for a change -- to set the installation directories to a custom prefix. (Yes, Mr. Boat-on-Water saying sometimes you really need a road, with curbs, streetsigns, and traffic lights), This is just one of those cases where sometimes the easy was isn't the right way. [*] Inspection of the automake-1.9 cygport shows that the only code changes in our automake are the libobj fixes (ignoring testsuite changes and documentation). But, that means the generated Makefile.in's will be different than ones created by pristine automake. Leading to un-necessary (and thus, rejected) changes to those Makefile.in's when submitting patches. Perhaps we could drop the libobj support from our am-1.9 packages? Sure, but then IIRC cygwin libtool (1.5 only? also 2.2? Can't recall.) will fail some of its regression tests -- with possible real-world consequences for packages other than gcc/binutils. Another idea: because our /usr/bin/automake-1.9 modifications directly affect only the actual /usr/bin/automake-1.9 file itself (and not any of the .m4 files and stuff in /usr/share/automake-1.9/), I *could* just make a very small package that includes only a /usr/bin/automake-1.9bis file, with a different alternatives priority. But the automake rules don't know about AM_VERSION=1.9bis, only =1.9. So that won't work. Third idea: A "sub-alternatives" arrangement for "ok, automake -> automake-1.9, but automake-1.9 -> either "regular" or "gcc" am19". good golly, no. That's just...ick. It would work, but... So, IMO the least bad solution is a completely separate am-1.9-pristine installed outside of /usr. And thus, ac-2.59 also installed outside of /usr. It does mean that Dave has to remember to set his PATH properly -- but he can do that inside the gcc4.cygport once and for all. [**] I'm cheating a bit with regards to libtool, as I haven't made a gcc-tools-libtool package. But that's because I think it is probably not necessary for Dave et. al. to try to update the libtool stuff in the gcc tree; it's already at git-master post-2.2.6-release; Ralf W. has been keeping it reasonably up to date; and you don't use libtoolize to do it, anyway. You manually copy the relevant m4 files -- sadly, libtoolize makes a hash of the src/ tree. At least it did the last time I tried to do it that way. -- Chuck