Re: [Paparazzi-devel] airframe editor, getting started for new users and airframe file pollution

[Felix Ruess]

Hi Gerard,

it's great that you are thinking about how to best approach this and create some sort of wizard that could handle the most common setup problems.

But I'm not convinced that writing complicated XSD schemas is the way to go as to me it seems quite hard to encode all this (although you are welcome to prove me wrong ;-)

In general I'm a fan of not duplicating the information and encoding dependencies, etc. in a parallel definition that is otherwise not used/needed.

IMHO it would be best to keep this information "close to the code" and extract as much as possible from that.

In the past we already tried a (simple) approach to list at least possible subsystems with their options in an xml file (conf/firmwares/rotorcraft.xml), but it was cumbersome to keep up to date and not really used. I will actually just delete those as they are of no use...

The most promising way I can currently think of is also using an xml file for subsystems (instead of just a makefile), so basically an enhanced version of the module xml.

Or even get rid of the module/subsystem distinction with that...

That makes it easier to parse and list dependencies and conflicts. See also https://github.com/paparazzi/paparazzi/pull/1007

Of course that still doesn't give you all allowed sections/defines for the airframe file, but we could start by using the documented configure/defines from the xml.

Christophe also worked on an airframe editor that should be able to list available subsystems and reorganize the airframe file: sw/tools/airframe_editor/airframe_editor.py

But that would need a lot more love...

Not quite sure I understand what you mean with the "update_environment" script...

Cheers, Felix

On Tue, Dec 2, 2014 at 8:36 PM, Gerard Toonstra <address@hidden> wrote:

I've been thinking about the above problems.

A standard for generating and validating XML files is XSD. This describes the format of the XML file, the datatypes and imposes constraints on how they are put together. If we set up such an XSD, we can validate all airframe files against this definition and trap errors a bit early, or trap issues where certain config items no longer have effect as support disappeared, or whatever. So it's not only useful to validate what exists now, but also in cases where new airframe files are being developed and add this as a pre-validation stage prior to compilation.

For the editor:  I thought about this in detail and in all paths I considered I think we end up writing a fully blown editor which takes a lot of effort and I don't think it's justified considering the frequency at which new airframe files are made.

A wizard like application is something that comes close. The XSD will contain a large amount of choices that can be made (rotorcraft | fixedwing), etc.  So for some of the choices we allow the user to specify what subelements should be inserted and then reapply the element factories to rebuild the document so far, eventually leading to a document that contains a general layout of the user-specific configuration.  The XML is then generated and the user can tweak the generated values by hand (or remove them?). The choices offered will have to be picked by us, because it requires custom code to be inserted.

I think for getting the development environment figured out, we could consider using xpath to see if specific special rules apply that need to update the environment. This could be a simple "update_environment" script that reads the airframe being considered and then launches rules to pull things from git or "git update" submodules or whatever.

What do you think?  Does this sound too complicated?

Rgds,

Gerard

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel