[okl4-developer] OKL4 v2.1: Missing dependency checks for weaver.xml

[Frank Kaiser]

Hello

 

When I started with my new platform by writing the machine's class
definition I made a typo with a memory definition: the end address of
the range was lower than the begin address. The outcome was an invalid
syntax the file 'weaver.xml', something like:

             <region base="0x20000000" size="0x-1DC00000"
type="conventional" />

Of course ELFWEAVER complained about the invalid number. It was not a
big deal to find the cause and correct the values in 'machines.py'.
After that I just restarted the build and "wham!", the error reappeared.
An inspection of the build log showed that SCONS just did not rebuild
'weaver.xml'. Apparently SCONS does not have any knowledge about the way
this file is created, and therefore it does not know its dependencies.

What I found is that the file is not created within a
SConstruct/SConscript file, but within the Python script
'tools/build.py'. It is done by the method 'GenWeaverXML()' of class
'KengeEnvironment'. I could fix the problem with the following
statements inserted before the method's 'return' statement:

        mfile = "#" + os.path.join("platform",
self.machine.platform_dir, "tools", "machines.py")

        Depends(weaver, mfile)

However, I thing this is not the whole story. For instance, the platform
class definition inherits items from a base class defining the processor
architecture (in my case it is 'arch/arm/tools/machines.py'); changes
there still would not trigger a rebuild of 'weaver.xml'. In general, for
a reliable build system any script content affecting the result of the
build should establish a dependency.

Another point is whether the build system correctly maintains
dependencies of all build artefacts to 'weaver.xml'. To find out I made
a test (command line is 'tools/build.py MACHINE=sam9263 PROJECT=iguana
BUILD_DIR=\"sam9263\" --debug=explain'):

*       I started the build two times with the same configuration and
command line so that I got an "up-to-date" message the 2nd time.

*       I modified the physical memory range of my machine.

*       I started the build another time with the same configuration and
command line.

With my additonal dependency check I get this result:

scons: rebuilding `sam9263/images/weaver.xml' because
`platform/at91/tools/machines.py' changed

[XML ] sam9263/images/weaver.xml

scons: rebuilding `sam9263/images/image.elf' because
`sam9263/images/weaver.xml' changed

[ELF ] sam9263/images/image.elf

scons: rebuilding `sam9263/images/image.sim' because
`sam9263/images/image.elf' changed

[ELF ] sam9263/images/image.sim

scons: rebuilding `sam9263/images/image.boot' because
`sam9263/images/image.elf' changed

[ELF ] sam9263/images/image.boot

scons: rebuilding `sam9263/images/image.boot.bin' because
`sam9263/images/image.boot' changed

[BIN ] sam9263/images/image.boot.bin

scons: done building targets.

Only the artefacts of the ELFWEAVER are rebuild, and I doubt that this
is sufficient. For instance, what about the bootinfo source files? Do
they have no dependency to the machine's class definition?

For another test I removed a coprecessor #define (extension of attribute
'cpp_defines') from my machine's class definition. That seems to be
handled correctly, since I get the following result (excerpt):

scons: rebuilding `sam9263/pistachio/l4kernel/object/src/asid.o' because
the contents of the build action changed

               action: $CXX $_CXX_COM_FLAGS $_CXXFLAGS $_CPPDEFFLAGS
$_CPPINCFLAGS $SOURCES -c -o $TARGET

[CXX ] sam9263/pistachio/l4kernel/object/src/asid.o

scons: rebuilding `sam9263/pistachio/l4kernel/object/src/assert.o'
because the contents of the build action changed

               action: $CXX $_CXX_COM_FLAGS $_CXXFLAGS $_CPPDEFFLAGS
$_CPPINCFLAGS $SOURCES -c -o $TARGET

...

That does look good.

Next try is adding a virtual timer to the platform:

    v2_drivers = [

                    (timer_driver, "vtimer", memory_timer,
interrupt_timer)

                 ]

This change is recognized by building some additional Iguana stuff and
rebuilding the image (excerpt):

scons: rebuilding `sam9263/images/weaver.xml' because:

           `sam9263/iguana/bin/vtimer' is a new dependency

           `platform/at91/tools/machines.py' changed

[XML ] sam9263/images/weaver.xml

scons: rebuilding `sam9263/images/image.elf' because:

           `sam9263/images/weaver.xml' changed

           `sam9263/iguana/bin/vtimer' is a new dependency

[ELF ] sam9263/images/image.elf

scons: rebuilding `sam9263/images/image.sim' because:

           `sam9263/images/image.elf' changed

           `sam9263/iguana/bin/vtimer' is a new dependency

[ELF ] sam9263/images/image.sim

scons: rebuilding `sam9263/images/image.boot' because
`sam9263/images/image.elf' changed

[ELF ] sam9263/images/image.boot

scons: rebuilding `sam9263/images/image.boot.bin' because:

           `sam9263/images/image.boot' changed

           `sam9263/iguana/bin/vtimer' is a new dependency

[BIN ] sam9263/images/image.boot.bin

scons: done building targets.

This shows that new dependencies are recognized as long as build
artefacts derived from source files defined in SConstruct/SConscript
files are affected. But what about changing a driver property in
'machines.py', for instance the driver's interrupt number?

scons: done reading SConscript files.

scons: Building targets ...

Couldn't find a header posix/limits.h when scanning
sam9263/iguana_server/include/limits.h

Couldn't find a header posix/limits.h when scanning
sam9263/iguana/include/limits.h

Couldn't find a header posix/limits.h when scanning
sam9263/iguana/include/limits.h

scons: rebuilding `sam9263/images/weaver.xml' because
`platform/at91/tools/machines.py' changed

[XML ] sam9263/images/weaver.xml

scons: rebuilding `sam9263/images/image.elf' because
`sam9263/images/weaver.xml' changed

[ELF ] sam9263/images/image.elf

scons: rebuilding `sam9263/images/image.sim' because
`sam9263/images/image.elf' changed

[ELF ] sam9263/images/image.sim

scons: rebuilding `sam9263/images/image.boot' because
`sam9263/images/image.elf' changed

[ELF ] sam9263/images/image.boot

scons: rebuilding `sam9263/images/image.boot.bin' because
`sam9263/images/image.boot' changed

[BIN ] sam9263/images/image.boot.bin

scons: done building targets.

Got it: 'weaver.xml' is rebuilt due to my change described earlier, but
the timer driver code responsible for the interrupt handling is not. The
'v2_drivers' attribute is evaluated in method
'KengeEnvironment.GenWeaverXML(), so the interrupt definitions find
their way into 'weaver.xml', but it is not clear how it gets into the
build image. There are also references 'projects/iguana/SConstruct'
which are somehow connected to the examples in 'iguana/example', so
these references seem not to be relevant when the examples are not used.

The outcome of all this is that I see room for improvements regarding
dependency checking on the OKL4 build system.

 

Regards

Frank

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