From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1KywAq-0002oz-8h for garchives@archives.gentoo.org; Sat, 08 Nov 2008 22:20:56 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 504E0E01BE; Sat, 8 Nov 2008 22:20:55 +0000 (UTC) Received: from qw-out-1920.google.com (qw-out-1920.google.com [74.125.92.144]) by pigeon.gentoo.org (Postfix) with ESMTP id 23320E01BE for ; Sat, 8 Nov 2008 22:20:55 +0000 (UTC) Received: by qw-out-1920.google.com with SMTP id 5so1544366qwc.10 for ; Sat, 08 Nov 2008 14:20:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:subject :message-id:mime-version:content-type:content-disposition:user-agent :sender; bh=pIQ0YVP5l7zexJjakstSNCWhgjS5AzYuY7cg4AN6pas=; b=EHebIMv1Pdh+91Qh2Tr7YQ0KP0B34qSDfjvavyrf6zPErDBmOX3XQCmlH0bG5y/VlU QJhaoFzZeZ1b/e7N8V/Px0fS9/ts0p5OAlYYTwezFQjeeqFmBroWxHQEKY59iCu3NyyQ yLZYcMah7nRUjdPwJ2xXoAMDLVgXrOzJ6RfXY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent:sender; b=jhWug2+AUJwQvy3SBDGokyOSBX7IN2tPeGuEFt6tbSJ9ptKgNSVltZ/CsIgzQBzJkd 8HESVf0MwIPLeD55Gm+PrAC2/IJESw/iOWhdrkRzaFwDdaA6tkcQ9jPlT6wopCxqc8j4 XN7KYBeWgcOFnf/ZlPVH+VpZJCfqIyl9OHenE= Received: by 10.214.116.7 with SMTP id o7mr5476869qac.133.1226182853386; Sat, 08 Nov 2008 14:20:53 -0800 (PST) Received: from smtp.gmail.com (c-69-249-154-72.hsd1.nj.comcast.net [69.249.154.72]) by mx.google.com with ESMTPS id 5sm12341088yxt.1.2008.11.08.14.20.52 (version=SSLv3 cipher=RC4-MD5); Sat, 08 Nov 2008 14:20:53 -0800 (PST) Received: by smtp.gmail.com (nbSMTP-1.00) for uid 1001 (using TLSv1/SSLv3 with cipher RC4-MD5 (128/128 bits)) gentoofan23@gentoo.org; Sat, 8 Nov 2008 17:20:52 -0500 (EST) Date: Sat, 8 Nov 2008 17:20:51 -0500 From: Thomas Anderson To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] DEFAULT_* proposal Message-ID: <20081108222051.GA7464@spoc> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ew6BAiZeqk4r7MaW" Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) Sender: Thomas Anderson X-Archives-Salt: e6575a97-3765-434d-9525-d4551870b3d2 X-Archives-Hash: 17e6ae8082aeb762fd01ba7307457789 --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [RFC] Simplifying functions with variables and help from the PM Hello All; This is a reposting of a call for discussion on DEFAULT_* variables. The original discussion was at [1]. The general idea is making the default functions support some new variables so that they are more flexible.=20 Here are the function(in order of execution) changes I propose, but let me first remind you that these changes are for the default package manager implementation of the functions. Each proposal is separate but it'd be nice if they all went in the same EAPI so it doesn't get confusing. src_prepare: DEFAULT_RSC_PREPARE_PATCHES[] This is a bash arrary list of patches to be applied to the sources. This is implemented as PATCHES or similar variables in a lot of eclasses like base, bzr, git, horde, kde, ruby, ruby-gnome2, subversion and x-modular but they all have unneeded differences. We'll need a function(say builtin_epatch, but=20 better names are needed) in the PM to handle patching. src_configure: DEFAULT_SRC_CONFIGURE_USE_ENABLES[] An array whose constants are passed as arguments to `use_enable`. Each value of the array can have two parts. DEFAULT_SRC_CONFIGURE_USE_ENABLES=3D( 'a52 a52dec' ) would translate to $(use_enable a52 a52dec). DEFAULT_SRC_CONFIGURE_USE_WITHS[] Same as above, but s/enable/with/ DEFAULT_SRC_CONFIGURE_EXTRA_PARAMS[] Array of options to pass to econf src_compile: DEFAULT_SRC_COMPILE_PARAMS[] Array of options to pass to emake src_install: All I want changed here is a variable for a list of extra docs to be installed. This'll require a default function for src_install and I propose: src_install() { emake -j1 install DESTDIR=3D"${D}" || die "make install died" [[ -n ${DEFAULT_SRC_INSTALL_DOCS} ]] && dodoc \ ${DEFAULT_SRC_INSTALL_DOCS} } bug #33544 has more information on this topic, as does tommy's recent thread on the subject of default src_install function. In my experience, these features greatly enhance ebuilds and make the ebuilds simpler to write(before objecting to this point, read the original thread[1] and/or use the feature), read, and maintain. Also, one point I cannot stress enough is that this is not meant for every ebuild but for the majority of simple cases. Now, last time around, objections were made to the effect that the src_configure proposal hides things in the PM which makes the learning curve higer and hides things from the ebuild viewer. My position on this is that it hides stuff in the same way that `use_enable mp3` hides `use mp3 && echo "--enable-mp3" || echo "--disable-mp3"`. In other words, not all cases where you move thinsg to the PM are bad. Credit for this idea goes to those who made the exheres package format(used for the Exherbo linux distribution) and those who participated in the discussion on bug #33544 over the past who knows how many years. Please discuss! Thomas Anderson [1]: http://article.gmane.org/gmane.linux.gentoo.devel/58038 --ew6BAiZeqk4r7MaW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEABECAAYFAkkWEMMACgkQF6yMcaBxwHkWJgCgn68lq+Pc7Vd4pHbd+uToGqpg XiAAnRzOADU448nXnUUNEw66TSuBhvgT =Pk55 -----END PGP SIGNATURE----- --ew6BAiZeqk4r7MaW--