[okl4-developer] OKL4 2.1: Symbols 'platform' and'platform_dir' in machine definition class ofplatform/<xxx>/tools/machine.py

[Frank Kaiser]

> -----Original Message-----
> From: Geoffrey Lee [mailto:glee at ok-labs.com]
> Sent: Friday, July 11, 2008 9:28 AM
> To: Frank Kaiser
> Cc: developer at okl4.org
> Subject: Re: [okl4-developer] OKL4 2.1: Symbols 'platform'
and'platform_dir'
> in machine definition class ofplatform/<xxx>/tools/machine.py
> 
> Hi Frank
> 
> The way that I understood your question was that we should
> be able to have one platform directory, and the differences
> can be based on the subplatform conditional compile define.
> When it comes to generating the boot image, you would need
> to edit the projects/iguana/SConstruct.  However, you may
> base the conditional tests on either the platform name,
> which you can obtain with machine.platform, or
> alternatively, the specific machine target with machine.__name__.
> 
> Hence, to summarize, you have one platform directory, and one platform
name.
> You however, have two machine targets, one for each variant.
> For each of those machine targets, you specify the platform
> field to be the same thing, because the build system picks
> the platform-specific code based on that.  However, they should
> have different subplatform names because you can use the subplatform
> name to determine which code to conditionally compile.  Am I
> misunderstanding your question in some way?  If I am, could
> you please reword or rephrase to help me understand what you
> are trying to achieve?
> 
> 
> 
> 
> 	-gl
---
Hi, Geoffrey

Let me try to give you an example of what I am trying to do. Here the
relevant part of my 'machines.py':
# ATMEL ARM9 Platforms

class sam9263(arm926ejs):
    virtual = False
    platform = "sam9263"
    platform_dir = "at91"
    boot_binary = True
    ...
###
And here comes my additional platform class:

class rm9200(arm920t):
    virtual = False
    platform = "rm9200"
    platform_dir = "at91"
    boot_binary = True
    ...
###
With my change in 'pistachio/SConscript' described earlier I expect no
problem by selecting either machine with the command line
	tools/build.py machine=sam9263 ...
or
	tools/build.py machine=rm9200 ...
Meanwhile I found out that the situation is even more complicated. Since
there are places in 'pistachio/SConscript' and
'projects/iguana/SConstruct' which evaluate the attribute 'platform', I
thought that its value also compares to the command line parameter
'machine'. But this is not the case: instead the parameter is compared
to the class name itself (tools/build.py, lines 293 to 299). The tricky
point is that the function 'handle_arg()' returns the value of the key
'MACHINE' as an object, and if a class exists having the name of the
object, then the assignment to 'self.machine' creates an object
reference to that class. If the class does not exist, then the returned
object is a string, and the build is stopped at the error check 'if
type(self.machine) == type(""):'.
The outcome of all this is that, against my earlier assumption, the
attribute 'platform' need not to be unambiguous. With an unchanged
'pistachio/SConscript' is could look like this:
# ATMEL ARM9 Platforms

class sam9263(arm926ejs):
    virtual = False
    platform = "at91"
    boot_binary = True
    ...
###

class rm9200(arm920t):
    virtual = False
    platform = "at91"
    boot_binary = True
    ...
###
As long as my platforms do not require special treatment in the build
system, I do not need to bother what 'pistachio/SConscript' is doing
with attribute 'platform', but that might change in the future.
Therefore I stay in favor of my change having a decoupling of the
platform name and the files' location.

Regards
Frank