From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1QbG5u-0008Mn-BQ for garchives@archives.gentoo.org; Mon, 27 Jun 2011 17:59:34 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BBCBE1C035; Mon, 27 Jun 2011 17:58:50 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 86CA01C035 for ; Mon, 27 Jun 2011 17:58:50 +0000 (UTC) Received: from mail-vx0-f181.google.com (mail-vx0-f181.google.com [209.85.220.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mattst88) by smtp.gentoo.org (Postfix) with ESMTPSA id 0056B1BC01C for ; Mon, 27 Jun 2011 17:58:49 +0000 (UTC) Received: by vxa40 with SMTP id 40so4348442vxa.40 for ; Mon, 27 Jun 2011 10:58:48 -0700 (PDT) Received: by 10.52.68.162 with SMTP id x2mr92195vdt.116.1309197528071; Mon, 27 Jun 2011 10:58:48 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-catalyst@lists.gentoo.org Reply-to: gentoo-catalyst@lists.gentoo.org MIME-Version: 1.0 Received: by 10.52.158.168 with HTTP; Mon, 27 Jun 2011 10:58:28 -0700 (PDT) In-Reply-To: <4E08C0DD.5010003@gentoo.org> References: <4E08C0DD.5010003@gentoo.org> From: Matt Turner Date: Mon, 27 Jun 2011 13:58:28 -0400 Message-ID: Subject: Re: [gentoo-catalyst] [rfc] simplifying arch classes To: gentoo-catalyst@lists.gentoo.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: X-Archives-Hash: 8f469fb8c93959ad0b0150909ccd0226 On Mon, Jun 27, 2011 at 1:41 PM, Sebastian Pipping wrote= : > On 06/27/2011 07:15 AM, Matt Turner wrote: >> class arch_mips(generic): >> =A0 =A0 "MIPS class" >> =A0 =A0 def __init__(self, Olevel, arch, additional_cflags, include_work= arounds): >> =A0 =A0 =A0 =A0 generic.__init__(self) >> >> =A0 =A0 =A0 =A0 self.settings["CFLAGS"] =3D "-O" + Olevel >> =A0 =A0 =A0 =A0 self.settings["CFLAGS"] +=3D " -march=3D" + arch >> =A0 =A0 =A0 =A0 if additional_cflags !=3D "": >> =A0 =A0 =A0 =A0 =A0 =A0 self.settings["CFLAGS"] +=3D " " + additional_cf= lags >> =A0 =A0 =A0 =A0 if include_workarounds: >> =A0 =A0 =A0 =A0 =A0 =A0 if arch =3D=3D "mips3": >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 self.settings["CFLAGS"] +=3D " -mfix-r40= 00 -mfix-r4400" >> =A0 =A0 =A0 =A0 =A0 =A0 elif arch =3D=3D "r4000" or arch =3D=3D "r4k": >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 self.settings["CFLAGS"] +=3D " -mfix-r40= 00" >> =A0 =A0 =A0 =A0 =A0 =A0 elif arch =3D=3D "r4300": >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 self.settings["CFLAGS"] +=3D " -mfix-r43= 00" >> =A0 =A0 =A0 =A0 =A0 =A0 elif arch =3D=3D "r10000" or arch =3D=3D "r10k": >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 self.settings["CFLAGS"] +=3D " -mfix-r10= 000" >> =A0 =A0 =A0 =A0 self.settings["CFLAGS"] +=3D " -pipe" > > Thoughts: > > =A0- How are you going to ensure that such refactoring keeps all > =A0 ~50 cases working without writing 50 explicit, data-duplicating > =A0 test cases? =A0Would you be willing to write these? There seems to be an implicit assumption that the current code has some kind of working test cases. :) This is certainly not the case. Let me be clear, mistakes in the current code come from having the same CFLAG, CHOST, etc strings duplicated in many places. Refactoring the code would allow us to catch mistakes like http://git.overlays.gentoo.org/gitweb/?p=3Dproj/catalyst.git;a=3Dcommit;h= =3Ddb4323146ce27362948de6eab57e1dbe28240bde much more quickly. It seems to me that test coverage would be much simpler if the classes were refactored, since various combinations would use nearly identical code paths. > =A0- The code above adds flexibility but is less obvious than > =A0 the current code. =A0So while it improves on one aspect > =A0 it worsens on another. Perhaps... I'm not sure I'd agree. I'm not sure 24 classes with only slight variations between them lends itself to being obvious. > =A0- Such refactoring would have to be done on both 2.x and 3.x branches. > =A0 Better wait until we are clear on their future. Yes, of course. Thanks, Matt