X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Message-ID: From: Jay To: cygwin Subject: managing autoconf versions? Date: Sat, 16 May 2009 06:00:30 +0000 In-Reply-To: <1242445850.26068.ezmlm@cygwin.com> References: <1242445850 DOT 26068 DOT ezmlm AT cygwin DOT com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com This is a little off topic. =20 How do people manage autoconf/automake versions? =20 =20 In particular, I'm not doing "my own work" -- I could probably just install= one recent version of everything and be ok. =20 =20 Rather I'm wondering about submitting patches to other projects, some proje= cts might use one set of versions, or another. Change configure.ac/Makefile= .am or such and regenerate configure/Makefile.in or such, using a matching = toolset version so that churn is only what is desired? =20 =20 Is the solution to install to various custom prefix and tailor $PATH based = on context? Or does one "wrapper" sniff the input or output and decide amon= g the versions installed in a standard place? You know, like, input/or output could say # use autoconf 1.2.3 and then /usr/bin/autoconf could delegate to /usr/bin/autoconf-1.2.3 or such? =20 Thanks, - Jay -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/