Refactor/plugin header split#1506
Conversation
|
|
||
| /** | ||
| * @file plugin_impl.h | ||
| * @brief Plugin implementation macros — included only by plugin.c. |
There was a problem hiding this comment.
It its only included inside plugin.c why do we need a header for it?
There was a problem hiding this comment.
It felt cleaner that way, keeping the .c file focused on the actual logic instead of dealing with macros. The impl header also needs to #undef and redefine several macros before re-expanding plugin_def.h a second time so that's ~60 lines of macro machinery that could clutter plugin.c if inlined.
What do you think?
There was a problem hiding this comment.
I think, having it is fine and for my taste plugin.c still contains too many macros/defines (which is no way speaking to this PR but rather to the structure that is in place).
There was a problem hiding this comment.
I did notice there is still some kind of problem around plugin_def.h. If that one receives an include guard, linking fails. I have not been able to look into this further
|
wow, thank you for this! :-) |
| #define NAVIT_PLUGIN_IMPL_H | ||
|
|
||
| #include "plugin.h" | ||
| #include <glib.h> |
There was a problem hiding this comment.
I think including "glib.h" is better here, if we want to continue supporting platforms without native glib.
3 participants
Addresses #1439
Our current code was maybe slightly abusing the list macros here.