Re: [gentoo-catalyst] [rfc] simplifying arch classes

[Matt Turner <mattst88@gentoo.org>]

On Mon, Jun 27, 2011 at 1:41 PM, Sebastian Pipping <sping@gentoo.org> wrote:
> On 06/27/2011 07:15 AM, Matt Turner wrote:
>> class arch_mips(generic):
>>     "MIPS class"
>>     def __init__(self, Olevel, arch, additional_cflags, include_workarounds):
>>         generic.__init__(self)
>>
>>         self.settings["CFLAGS"] = "-O" + Olevel
>>         self.settings["CFLAGS"] += " -march=" + arch
>>         if additional_cflags != "":
>>             self.settings["CFLAGS"] += " " + additional_cflags
>>         if include_workarounds:
>>             if arch == "mips3":
>>                 self.settings["CFLAGS"] += " -mfix-r4000 -mfix-r4400"
>>             elif arch == "r4000" or arch == "r4k":
>>                 self.settings["CFLAGS"] += " -mfix-r4000"
>>             elif arch == "r4300":
>>                 self.settings["CFLAGS"] += " -mfix-r4300"
>>             elif arch == "r10000" or arch == "r10k":
>>                 self.settings["CFLAGS"] += " -mfix-r10000"
>>         self.settings["CFLAGS"] += " -pipe"
>
> Thoughts:
>
>  - How are you going to ensure that such refactoring keeps all
>   ~50 cases working without writing 50 explicit, data-duplicating
>   test cases?  Would 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=proj/catalyst.git;a=commit;h=db4323146ce27362948de6eab57e1dbe28240bde
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.

>  - The code above adds flexibility but is less obvious than
>   the current code.  So while it improves on one aspect
>   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.

>  - Such refactoring would have to be done on both 2.x and 3.x branches.
>   Better wait until we are clear on their future.

Yes, of course.

Thanks,
Matt