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

[Geoffrey Lee]

On Wed, Jul 09, 2008 at 10:58:34AM +0200, Frank Kaiser wrote:

> Hello, Geoffrey


Hi Frank

> 
> Thanks for hinting me on that 'CONFIG_SUBPLAT_XXX define' scheme (I
> found it now in 'pistachio/Sconscript'). Is this documented anywhere? My
> current knowledge of the build system is mainly based on analysing the
> build scripts.
> The other platform I'd like to support is based on an AT91RM9200 which
> uses an ARM920T core. Therefore its 'machine' definition has to inherit
> the class 'arm920t' while the other one (based on AT91SAM9263) inherits
> class 'arm926ejs'. If I got it right, this requires two separate class
> definitions for each machine which have to have a different 'platform'
> value, otherwiese the script code in 'tools/build.py', which reads all
> 'machine' classes and selects the platform to be used for build, would
> get confused.

Yes, in this case you would need to inherit from different CPU 
classes.

I think you should be able to point the platform to the same platform
directory.  For example, the pxa platform directory is shared, though
currently the only supported machine type is Gumstix.

> Despite the different cores both processors have a number of identical
> peripherals so that I can reuse at least 3/4 of my platform-dependent
> code. So I get to the point that I have one source code directory but
> two platforms with different names, and I see no other option but to
> decouple the platform name from the platform directory as I have done.
> My remark on other disadvantages of the 'subplatform' scheme was mainly
> driven by some script code in 'iguana/Sconstruct' (line 826ff), where
> default build targets and other stuff are defined dependent on the
> selected machine.

You can use machine.__name__ to get the name of the machine as
a text string, rather than testing for the platform value.


> 
> Regards
> Frank

	-gl

> 

--