FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Catalyst

 
 
LinkBack Thread Tools
 
Old 06-27-2011, 05:15 AM
Matt Turner
 
Default simplifying arch classes

The arch class structure ({alpha,amd64,mips,hppa,etc}.py files) are a
lot of typing for the small number of attributes they synthesize. This
makes them prone to typing errors.

Consider mips.py. It supports big and little endian; mips 1, 3, 4,
loongson, cobalt; o32, n32, n64, multilib ABIs. Almost every
combination of these attributes exists as a hard-coded class, leaving
us with 24 builder and 5 abstract base classes.

Wouldn't it be simpler to pass in some information into an arch_mips
class and let it generate the requested attributes. Something like
this:

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"

Clearly a simplistic and incomplete example, but it should be enough
to understand the idea.

Thanks,
Matt
 
Old 06-27-2011, 05:41 PM
Sebastian Pipping
 
Default simplifying arch classes

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?

- The code above adds flexibility but is less obvious than
the current code. So while it improves on one aspect
it worsens on another.

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

Best,



Sebastian
 
Old 06-27-2011, 05:58 PM
Matt Turner
 
Default simplifying arch classes

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=db4323146ce27362948de6eab5 7e1dbe28240bde
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
 
Old 06-27-2011, 06:18 PM
Sebastian Pipping
 
Default simplifying arch classes

On 06/27/2011 07:58 PM, Matt Turner wrote:
> There seems to be an implicit assumption that the current code has
> some kind of working test cases.

I'm aware that I'm asking for test cases in context that seems to lack
proper testing.


> 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=db4323146ce27362948de6eab5 7e1dbe28240bde
> 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.

It would make some code pathes being taken more often but still leave
the "leafes" ontouched without a test for each leaf. Right?

What could work though is a throw-away test for refactoring only, say
writing a piece of code making a text file listing all combination of
CFLAGS offered from targets. If after the refactoring you get the very
same text file out, that's a good indicator. Is the idea clear?

Best,



Sebastian
 
Old 06-27-2011, 06:24 PM
Matt Turner
 
Default simplifying arch classes

On Mon, Jun 27, 2011 at 2:18 PM, Sebastian Pipping <sping@gentoo.org> wrote:
>> 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=db4323146ce27362948de6eab5 7e1dbe28240bde
>> 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.
>
> It would make some code pathes being taken more often but still leave
> the "leafes" ontouched without a test for each leaf. *Right?
>
> What could work though is a throw-away test for refactoring only, say
> writing a piece of code making a text file listing all combination of
> CFLAGS offered from targets. *If after the refactoring you get the very
> same text file out, that's a good indicator. *Is the idea clear?

Yep, that should work and wouldn't be very much work. That seems like
a good idea.

Thanks!
Matt
 

Thread Tools




All times are GMT. The time now is 02:48 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org