Different logging for plugins

WOLF_DEBUG was designed to print only if compiled in "debug" mode. This was before splitting the library in plugins. Now, since this macros are defined in core, all WOLF_DEBUGs in whichever plugin prints depending on core compilation mode.

However, if I am working in a plugin, I may want to display the WOLF_DEBUG of my plugin but not the ones for the rest of the plugins. And also, I may want not to recompile core in "debug".

It would be very useful to activate/deactivate the WOLF_DEBUG of each plugin depending on the compilation mode of the corresponding plugin. I don't know how much difficult would it be, I assume it is not trivial.

added Agreement required Idea enhancement labels

I have compiled core in release mode, installed, and then compiled laser in debug mode and I can see the WOLF_DEBUG of the laser plugin but not the ones from core (so working as intended).

If you have tried with some plugin and is not working let me know and I'll test it as well.

Oh really? bffff..

Maybe it actually only works sometimes, depending on your include hierarchy. I recall having the same issue you describe when working on the demo. I will do a couple more tests.

If I compile core in release mode and the laser plugin in debug mode, then when running the demo I do not get debug messages although the laser plugin is in debug mode, so the behaviour is actually not consistent but I do not know why.

added bug label

added To Do (release) label and removed Agreement required label

removed Idea enhancement labels

Agreement:

Try this:

Change wolf.h L12: modify #include "core/internal/config.h" changing "core" by the plugin that is being compiled (with CMAKE variable or whatever)

I have ran this quick test:

Compile core in Release. Compile imu in Debug.

In gtest_processor_imu:

If the first includes of the file are arranged like so

#include "imu/internal/config.h"
#include "imu/capture/capture_imu.h"
#include "imu/processor/processor_imu.h"
#include "imu/sensor/sensor_imu.h"

Then we get WOLF_DEBUG macros in imu.

If the first includes of the file are arranged like so

#include "imu/capture/capture_imu.h"
#include "imu/processor/processor_imu.h"
#include "imu/sensor/sensor_imu.h"
#include "imu/internal/config.h"

Then we don't get WOLF_DEBUG macros in imu.

For the time being, to get the behaviour we are interested in, it seems that we just need to make sure to first include the plugin config.h before any other includes puts the core/config.h.

This is a temporary quick fix to obtain the desired behaviour. I will keep on working on the agreement.

created merge request !374 (merged) to address this issue

mentioned in merge request !374 (merged)

I don't think we can try the meeting agreement because, If I understand correctly, what CMake would generate is a new wolf.h file with this line

#include "core/internal/config.h"

changed to

#include "{plugin}/internal/config.h"

But the old wolf.h would still be included.

That's what I think that is happening. Since imu is DEBUG and core RELEASE:

1. #include "imu/internal/config.h" -> #define _WOLF_DEBUG
2. other includes -> #include "core/common/wolf.h -> #include "core/internal/config.h -> /* #undef _WOLF_DEBUG */ (not defined)

Then, _WOLF_DEBUG is defined and therefore WOLF_DEBUG are printed in the compiled code (imu).

But if you try to compile in the vice-versa build types (devel in DEBUG and imu in RELEASE), I'm pretty sure that imu WOLF_DEBUG messages will also be printed.

I think that we should work on the guards. The same guards in config.h would allow to define (or not) _WOLF_DEBUG and/or _WOLF_TRACE only once (the first time any config.h is included).

closed via merge request !374 (merged)

mentioned in commit 1ffeecd5

Sorry, why this issue has been closed? What has been implemented in this MR? How is only removing includes making it work?

reopened

Sorry I did not mean to close the issue, I just merged these changes and of course the issue was closed.

The #include "core/utils/logging.h" is the 2nd line of code of wolf.h, so all other includes of logging.h in gtests are redundant. I removed them, that's all.

I have experienced cases where depending on the order of includes, the behavior is unpredictable.

Either we remove it from wolf.h, or we fix the include order issue which I dont' know how to tackle -- including issues are horrible.

As I said in the previous comment, now, the order is not the only thing to consider.

We should use the same guards for all config.h files of all plugins, otherwise the case core in DEBUG and imu in RELEASE will print DEBUG messages of both plugins even if we include first the config.h of imu.

If we use the same guards, then we can focus on the order of includes.