From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 5ACC7198005 for ; Sun, 24 Feb 2013 04:22:57 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1D405E0618; Sun, 24 Feb 2013 04:22:49 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 3E6FCE05F9 for ; Sun, 24 Feb 2013 04:22:48 +0000 (UTC) Received: from [192.168.4.5] (blfd-4db13500.pool.mediaWays.net [77.177.53.0]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: hasufell) by smtp.gentoo.org (Postfix) with ESMTPSA id 14A4333DE3E for ; Sun, 24 Feb 2013 04:22:46 +0000 (UTC) Message-ID: <51299593.1010902@gentoo.org> Date: Sun, 24 Feb 2013 05:22:43 +0100 From: hasufell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130123 Thunderbird/17.0.2 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] New eclass: autotools-multilib-minimal References: <51296027.705@gentoo.org> In-Reply-To: <51296027.705@gentoo.org> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: b6978546-23a9-424c-9c9a-df4c58abd311 X-Archives-Hash: 6a897eb3894ed6be8931ecafb1652098 Before people start asking I should explain why I started this: https://bugs.gentoo.org/show_bug.cgi?id=458638 I think having such an eclass has several advantages over autootools-multilib.eclass (which depends on autotools-utils.eclass) as it is now: a) Less eclass dependencies. One could argue: the more eclasses my ebuild uses the more prone to error and exposed to changes it is. b) easier conversion in some cases: often times a simple rename src_compile -> multilib_src_compile will do c) it allows more custom definition of phase functions d) the previous point will also allow to convert go-mono.eclass packages without introducing yet another eclass for that e) autotools-utils.eclass does a bit more than just calling default phase functions; the developer has little choice on this matter unless he wants to rewrite his ebuild based on multilib-build.eclass which will create a lot of code duplication in ebuilds, hence this proposition I don't have a problem with the present eclasses, but I find this a logical enhancement.