feature: auto generate of support yaml to include pvi

[gilesknap]

We have a nice auto generator to make support.yaml from builder.py files.

It's here: https://github.com/epics-containers/ibek/blob/main/builder2ibek.support.py

At present this does not add the pvi: dictionary into each device. It's not a builder thing but would be nice to have (but maybe I'm biased because I'm working on AreaDetector with its 40 or so devices - many support modules would have only 1).

The process could be:

• use pvi to generate all of the *.pvi.device.yaml files in your ibek-support folder.
• perhaps manually fix up those yaml
• run builder2ibek.support.py to generate xxx.ibek.support.yaml but also point it at the *.pvi.device.yaml so it can add the pvi: entries.

@coretl is this worth it? I'm currently maintaining an auto generation of the the support.yaml here and the pvi thing is breaking it - but once we have support.yaml fully done we can forget about converters really.

[coretl]

@GDYendell I think this comes down to how much the autogenerated pvi yaml files will have to change. If we can live in a world where ibek and pvi files are autogenerated for long enough for the syntax to settle, then we should add support to builder2ibek. We also need to think about what happens when we add a new record to a template, can we use the pvi converter to append to an existing pvi file?

[GDYendell]

Is there a way to tell in the convert which builder objects have a corresponding pvi yaml? I guess if there is a yaml file with the same name as the class it should use it?

Whether it is worth it also depends on epics-containers/pvi#60

[gilesknap]

I think I've change my mind about this. builder.py is not going to be maintained going forward so we need to treat the conversion as a one-off. So adding pvi manually is acceptable. #60 I feel is more important because the pvi conversions come from active sources.