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

[Frank Kaiser]

Hello

 

When I started the implementation of my new hardware platform
AT91SAM9263, I wondered about the distinction of these to symbols. The
naming suggest that platform is the name by which the target is
referenced in the command line tools/build.py MACHINE=<platform> ...
while platform_dir is the location where the platform-specific files
should reside. However, the observation was that in given examples the
values were the same.

Since I foresee that we will have another ATMEL platform which is quite
similar to the current one, I plan to draw it from the same platform
directory. The few differences can well be controlled by a preprocessor
directive. For this purpose I could either create my own one by adding
it to cpp_defines, or make use of MACHINE_<platform> which is
automatically created.

However, an attempt to change the name of the platform directory and
adapt platform_dir accordingly made the build fail. It turned out that
the value of platform_dir is nowhere considered in the build scripts,
effectively rendering it useless. The main reason for this behaviour is
found in pistachio/SConscript around line 76:

platform = env.machine.platform

platform_dir =  "#" + os.path.join("platform", src_platform,
args["package"])

These two statements establish the platform path from the value of the
symbol platform while the value of platform_dir is ignored. Since
changing the first line to 'platform = env.machine.platform_dir' would
not work, because 'platform' is used several times further on in
pistachio/SConscript where it must deliver the platform name and not the
directory, I made the following change:

platform = env.machine.platform

# FK: make the platform file location distinct from the platform name

src_platform = env.machine.platform_dir

platform_dir =  "#" + os.path.join("platform", src_platform,
args["package"])

This works as expected, and I would appreciate is this could go into the
next version of OKL4.

There is another concept to support multiple platforms from the same
sources: that is introducing subplatforms. However, this approach
requires their introduction into the generic build scripts of PISTACHIO
and IGUANA (as can be seen with the s3c2410 platform), that is why I
dismissed this solution.

 

Regards

Frank

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.okl4.org/pipermail/developer/attachments/20080708/b359db26/attachment.htm