> Counter offer: Lets put a `platform.py` with a bunch of (stateless)
> callbacks invoked by the library builder in the folder with the device
> files.

Dang it, I just wanted to extract the platform generation mechanism, not
write a completely new one :-)

> It would contain:
> 1. a function that splits the device identifier string into a target
> dictionary and returns that.
> The library builder itererates over all `platform.py` in the folders and
> executes that first callback.
> All further hooks are used from that file then.

Having the naming as part of the XML file would make it useful for other
purposes as well. It would then capture all the core characteristics of the
device in one data format.

> 2. a function mapping the target dictionary onto a device file.
> The device file naming scheme is then local to only the folder and can
> therefore transparently hide differences in the target dictionary.
> 3. a function adding platform dependent Jinja2 filters.

What would be an example of these Jinja2 filters? Where are those stored
at the moment?

> I believe that these three function will allow the build system to be
> completely ignorant of the content of the target dictionary.
> Only the driver templates will have to understand what the target
> dictionary looks like.


> Regarding `driver.xml`: It's functions disguised as data. That's
> The library builder has the right idea.
> Let's use a `driver.py` that's called with a copy of the entire (!)
> substitution dictionary and it can modify it as it wishes.
> It can filter it, add and remove data, or create an entirely new
> substitution dictionary.

As long as the edited dictionary is specific to the driver thats easy, if
the other driver should get access to the edits than it gets much more

>> Btw. according to the device files xpcc supports 573 different targets
>> at the moment :)
> Not all combinations are valid though, some simply don't exist.
> The ORing is a one way mapping.

Damn. I still think having a two way mapping is very helpful. E.g. it
would allow to check that the generated code compiles for __all__ devices.
Is there any way to check which devices are non-existent? I guess it is
mostly a problem of the STM32 families? For the AVRs the number of devices
per device file is much lower.

>>> Could we have a base schema and then "specialize" that for the
>>> architectures?
>> That is possible, but a bit difficult. Inheritance is supported on tag
>> level, but not on schema level. With that most of the schema has to be
>> rewritten for that.
> Hm, ok.
> Would that mean that each platform has it's own schema (in the device
> folder?), with duplicate common code?

You can have common type definitions in a base schema, but the specific
schema needs to define the tag structure up to the point where it diverges.
Therefore it is easier to put the common part deeper in the tag tree than
the other way around.

>> PS: (...)/platform/devices/avr/at90646_647_1286_1287-usb.xml looks
>> broken with flash, ram and eeprom being defined multiple times with
>> different values without any selector.
> That looks like it would have been caught with a schema ;-P

Not sure about that. You would have to check that a tag together with the
values of all its attributes is unique. For required attributes that is
possible, but I'm not sure about optional attributes.

xpcc-dev mailing list

Reply via email to