Flight plan modules

[gautierhattenberger]

Yet another modules feature: load modules directly from a flight plan.

This should make easier to configure airframe so that they match the flight plans when they need specific modules.

[flixr]

Good idea!

But I wonder what happens (or even should be expected) if you have the module specified in your airframe file and in the flight plan?
Is it added twice? Only one of the two? Or merged in case one of them has extra define/configuration parameters?

[gautierhattenberger]

@flixr I don't know yet, this is a draft to see what you guys think about this. I guess that the filtering on the flags and source files will just "merge" the two modules, but on the modules.h generation, maybe functions will appear twice. I should probably merge them before that when building the modules' list. I'll do that if it is worth the effort. @dewagter @fvantienen @OpenUAS you are using flight plans with various modules a lot I guess, what do you think about this ?
If the modules dependency system had been done already, I guess it would have been better to specify these dependency rather than loading them directly...

[gautierhattenberger]

Merging modules is working now. Delft, do you have an opinion about this feature ?

[dewagter]

@gautierhattenberger thank you for this feature: this is a great way to

• cleanup airframe files
• have less copies of airframe files
• improve structure: what belongs where: nav_line is a flightplan feature

It also confirms one of the special aspects of paparazzi: flightplans are really full programs, and module includes make this more obvious.

[gautierhattenberger]

@flixr can I merge or you prefer more test cases ?

[flixr]

So what is the merging behaviour now if you have the module added twice?
Does it merge the defines/configures? Does it print an info that it was merged?
What happens if you have the same define/configure option in each of them but with different value?

[gautierhattenberger]

Now, defines/configure are aggregated (btw, I think I forgot to allow define/configure in flight plan...) but duplicates or incompatible parameters are not removed. "Real" duplicates will be merged at compile time by the sort function of the makefile. Incompatible will most likely produce compile errors (this can be improved later when people actually use the feature).
What is missing now is a debug print telling modules were merged. I will add that.

[flixr]

I still think that we should check for duplicate define/configure options (but not bother with the value) and throw an error (or at least a warning) in that case.
For configure options you will end up with one of the two, but you have no clue which one... for defines you might get a warning or compile error...