From owner-freebsd-ports@FreeBSD.ORG Tue Nov 15 15:42:42 2005 Return-Path: X-Original-To: ports@freebsd.org Delivered-To: freebsd-ports@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 01E7A16A421; Tue, 15 Nov 2005 15:42:42 +0000 (GMT) (envelope-from ade@lovett.com) Received: from mail.lovett.com (foo.lovett.com [67.134.38.158]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D67943D49; Tue, 15 Nov 2005 15:42:41 +0000 (GMT) (envelope-from ade@lovett.com) Received: from hellfire.lab.lovett.com ([10.16.32.20]:57466) by mail.lovett.com with esmtpa (Exim 4.54 (FreeBSD)) id 1Ec2xE-000Hoz-IG; Tue, 15 Nov 2005 07:42:40 -0800 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ade Lovett Date: Tue, 15 Nov 2005 07:42:40 -0800 To: ports@freebsd.org X-Mailer: Apple Mail (2.746.2) Sender: ade@lovett.com Cc: Ade Lovett Subject: Autotools New World Order X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2005 15:42:42 -0000 As some of you may have noticed, a tree-wide commit went in a short while back, radically changing the mechanisms for invoking the GNU autotools (automake, autoconf, libtool, et al) within the context of building a FreeBSD port. Without getting into the more religious issues, simply stated there is a requirement for a number of different versions of each autotool to co-exist on a machine in order to build various different ports. Previously, this required a myriad of different variables to be set, depending on the tool (or tools) that were required to build a port. These variables have now been collapsed into a single Makefile construct of the form: USE_AUTOTOOLS= :[:] ... where: can be one of 'libtool', 'libltdl', 'autoconf', 'autoheader', 'automake' and 'aclocal', specifies the particular tool revision to be used, and is an optional extension to modify how the tool is used. It cannot be stressed highly enough that these constructs, and the versioned autotools ports they use, are for use ONLY in building other ports. For cross-development work, the devel/gnu- {automake,autoconf,libtool} ports should be used, such as within an IDE. devel/anjuta and devel/kdevelop (GNOME and KDE respectively) are good examples of how to achieve this. Here's a simple conversion table from old to new: USE_LIBTOOL_VER=13 libtool:13 USE_INC_LIBTOOL_VER=15 libtool:15:inc WANT_LIBTOOL_VER=15 libtool:15:env USE_LIBLTDL=YES libltdl:15 USE_AUTOCONF_VER=213 autoconf:213 WANT_AUTOCONF_VER=259 autoconf:259:env USE_AUTOHEADER_VER=253 autoheader:253 (implies autoconf:253) USE_AUTOMAKE_VER=14 automake:14 WANT_AUTOMAKE_VER=15 automake:15:env USE_ACLOCAL_VER=19 aclocal:19 (implies automake:19) Note that the other variables associated with autotools - AUTOMAKE_ARGS, ACLOCAL_ARGS, AUTOCONF_ARGS, AUTOHEADER_ARGS, LIBTOOLFLAGS and LIBTOOLFILES are unchanged. Most ports do not need to concern themselves with these. Every effort has been made to create a new autotools usage method which is both extensible not only in terms of easily adding new versions if a drop-in upgrade is not possible, but also, through the keyword, of adding further tweaks with the minimum of fuss. By means of an example, compare the following sets of constructs, which says that a port wants the automake 1.9.x environment, needs to run both autoconf 2.53 and the associated autoheader as well as needing libtool 1.3.5 (with the second type of configure file patching), and the libltdl library. Previously, this would have been done with: WANT_AUTOMAKE_VER= 19 USE_AUTOCONF_VER= 253 USE_AUTOHEADER_VER= 253 USE_INC_LIBTOOL_VER= 13 USE_LIBLTDL= YES Now, we can reduce this to: USE_AUTOTOOLS= automake:19:env autoheader:253 libtool:13:inc libltdl:15 which vastly improves Makefile readability, whilst leaving the heavy lifting where it should be, in the infrastructural background, allowing for considerably easier implementation of ports that require the use of one or more autotools. The Porters Handbook is in the process of being updated with new text to reflect the changes (hi pav!). -aDe