Re: [Paparazzi-devel] Contributing to the Paparazzi project - Beginner questions

[Felix Ruess]

Hi Markus,

Do you mind if I add the highlighting?

Nope, go ahead.. :-) 

Is it a good idea to just have the module documentation in the doxygen docs and then just add a link in the wiki to the respective doxygen page for a module?
Imho it would be great to have both, since the wiki has pictures/figures.

IMHO both makes sense, but the essentials and specifically the available configure/defines should be in the module description in the xml file.

Especially since these can change with the paparazzi version..

 

- At some point we want to convert subsystems to the modules format as well (and use that in the same way to generate docs for them).

  Then we could also specify the matching settings files and automatically add them (see issue 23)

- For other generic defines/options, it would make sense to rethink the way we specify options. E.g. a generic macro to add a new option with description that can then be parsed by doxygen).

Hm. Since I'm new to paparazzi, I'd like to gain more XP first.
Sure, I could write the generic macro and some parser/doxygen magic to generate the list, but I still have limited experience with the code to sufficently test it afterwards.

Yeah, that needs some more thought about the bigger picture... 

About the paparazzi source code (available through github):
-) Upon installing the paparazzi-software package, I noticed that paparazzi has quite a lot of dependencies of which most look to be redundant.
    Less dependencies, imho ease code testing, maintenance and installation.
    Are there any plans to reduce the number of dependencies and external libraries?

Could you be a bit more specific? What do you mean by redundant dependencies?

In general it would be good to reduce dependencies if you can achieve the same thing with another lib we already have...

For example, to use ppz I had to install python (well, python was already installed), tcl-dev and ocaml-*.
Paparazzi uses afaik four 'programming' languages (python, tcl or it's libraries, C, ocaml) or more!?

I'm pretty sure we can get rid of tcl (I don't think that is actually used anywhere at the moment, at least I couldn't find anything that uses it)...

@Gautier, do you know why we (still?) have that dependency?

Getting rid of ocaml is not an option (at the moment) as the whole gcs, plotter and most other ground segment tools (including code/header generators) are written in ocaml.

Python in itself as a dependency should not be a problem and is nice to use...

C is obviously needed...

Additionally I had to install XML parsers for python and ocaml.

As our current main format to specify airframes, flight plans, etc. dropping xml is not an option. If we can get rid of dependencies to a specific xml parser is another question...

- For ocaml the xml-light parser is used (and I don't think there is a good enough xml parser provided by the standard ocaml lib, but I didn't really look into that).

- For python the lxml parser was originally used by the guys who wrote the settings and messages app, but I think there the ElementTree parser that already comes with python would be sufficient (e.g. when I wrote the modules doc generator I only used ElementTree).

  That being said, I had a discussion about the python xml parser with Christophe when he started writing an airframe editor gui using lxml: it turned out that the only thing we really want/need from lxml is DTD validation, the rest is doable with ElementTree.

 

Thus I thought that there are redundancies I could help to get rid of...

Well, most of these are not redundancies, but rather complement each other...

 

But: From your answer to my rather provocative question, I get that I should learn more about ppz before.

Probably... but it's good to raise such questions and some of the previous choices need to be revisited from time to time...

I just thought you have some more "specifc" dependencies in mind (we have some that are rather optional and only needed for some specific tools...)

 

If I find something I think can be done using another lib that's already in use, I'll write the necessary code and let you know.
Sorry, I did not mean to be rude!

No worries, you were not :-)

Cheers, Felix