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 07F901381F3 for ; Fri, 14 Jun 2013 13:45:06 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 56913E0943; Fri, 14 Jun 2013 13:45:01 +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 770B5E08E0 for ; Fri, 14 Jun 2013 13:45:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id B3B9033E2D2 for ; Fri, 14 Jun 2013 13:44:59 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -0.775 X-Spam-Level: X-Spam-Status: No, score=-0.775 tagged_above=-999 required=5.5 tests=[AWL=-0.381, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.392, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from smtp.gentoo.org ([IPv6:::ffff:127.0.0.1]) by localhost (smtp.gentoo.org [IPv6:::ffff:127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aq-DoQ-0qQjv for ; Fri, 14 Jun 2013 13:44:54 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id D054C33DA22 for ; Fri, 14 Jun 2013 13:44:52 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UnUJ6-00051p-Rn for gentoo-dev@gentoo.org; Fri, 14 Jun 2013 15:44:48 +0200 Received: from ppp118-209-15-147.lns20.mel4.internode.on.net ([118.209.15.147]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 14 Jun 2013 15:44:48 +0200 Received: from kensington by ppp118-209-15-147.lns20.mel4.internode.on.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 14 Jun 2013 15:44:48 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Michael Palimaka Subject: [gentoo-dev] Re: cmake-utils.eclass dropping EAPI 0/1 support Date: Fri, 14 Jun 2013 23:44:37 +1000 Message-ID: References: <51BA3E64.9020402@gentoo.org> <20130613183702.73622eca@gentoo.org> <51BA4C35.4030001@gentoo.org> <20130613190535.0d7d07a4@gentoo.org> 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: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ppp118-209-15-147.lns20.mel4.internode.on.net User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 In-Reply-To: <20130613190535.0d7d07a4@gentoo.org> X-Archives-Salt: 789e065d-9380-4faa-a01c-986135e83785 X-Archives-Hash: 264935c10087e12b45ecb44c5dd1520c On 14/06/2013 09:05, Alexis Ballier wrote: > On Thu, 13 Jun 2013 18:48:21 -0400 > Chris Reffett wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 06/13/2013 06:37 PM, Alexis Ballier wrote: >>>> At the beginning of July, the KDE team will be removing EAPI 0/1 >>>> support from cmake-utils.eclass and inlining the functions from >>>> base.eclass in order to remove that inherit [1]. >>> >>> So, instead of fixing what you consider wrong in base.eclass, you >>> inline it so that if someone improves base.eclass he has to do it >>> for cmake-utils too? >>> >> We did not actually inline most of the complicated logic from >> base.eclass, as to the best of my knowledge epatch itself will handle >> all of the corner cases that base_src_prepare covers. The new patching >> code essentially consists of [[ ${PATCHES[@]} ]] && epatch >> "${PATCHES[@]}"; epatch_user. > > that kind of stuff sounds more like it should be factorized rather than > copied all around; be it base.eclass, an EAPI, or another eclass I > don't really care. The code literally is '[[ ${PATCHES[@]} ]] && epatch "${PATCHES[@]}"'. Given that the actual epatch logic is in one place, I am not sure how much of an issue this really is. I think there's a proposal to put epatch into PMS too. Best regards, Michael