Add another library that only implements the bits needed for rock ports

[pierrewillenbrockdfki]

This is to allow rock tasks to actually provide the command creation and submission infrastructure for use with ports, without also pulling in vizkit3d and its qt dependency.

This has been tested to compile with a rock task with ENABLE_DEBUG_DRAWINGS active. Since there are no code changes relative to the full library(only removal of whole functions), i assume that this still works for tasks only using the rock ports mechanism. Otherwise, missing functions would have been found during linking the default deployments.

[pierrewillenbrockdfki]

This has become a bit bigger than anticipated; while adding tests, i found that one case did not compile: a library with ENABLE_DEBUG_DRAWINGS=ON using vizkit3d_debug_drawings-commands linked into an application with ENABLE_DEBUG_DRAWINGS=OFF using vizkit3d_debug_drawings.

Previously, the vizkit3d_debug_drawings in the library would have supplied the symbols, but there would not have been a Dispatcher installed. An exception would have been thrown whenever something tried to draw.

Now, the vizkit3d_debug_drawings-commands library will supply NOOP variants of all the relevant functions("working" the same as if ENABLE_DEBUG_DRAWINGS where OFF), but declared weak, so if vizkit3d_debug_drawings is linked in, its symbols have priority, and the calls in the library start working.

For testing the vizkit3d_debug_drawings-ports library, there is a link-time test consisting of a stripped down orogen component. The resultant deployment is deficient in many ways, but will run even though it cannot communicate meaningfully.

[pierrewillenbrockdfki]

@planthaber @chhtz this time, this is probably worth a look by a second pair of eyes.

[planthaber]

Looks good to me (didn't test).

So in a side-effect of using weak, the debugging is enabled for all libs that are linked together previously and not only the one linking it, right?.

I currently wonder if the overloading of weak functions also works when dynamically loading the lib later manually as a plugin. That way, we could load the lib "on demand" (e.g. with an operation, or by config option), while it is disabled during normal startup.

If this works, this could be a nice option for text logging, so you could load the "log_level_debug" plugin when you need debug text output, while when not loaded, no text output processing takes place at all (ecxept probably evaluating the function, as i expect weak functions are not optimized out in order to work).

[pierrewillenbrockdfki]

So in a side-effect of using weak, the debugging is enabled for all libs that are linked together previously and not only the one linking it, right?.

Weak is a flag on the symbol telling the linker to replace it with a non-weak version, if it finds one. This is in the same information block that holds the section, offset, size, name and other flags of the symbol. Debug information(line numbers, function arguments, types) does not come into play, these are the symbols used by the static and dynamic linker when resolving a variable access or function calls.

Running objdump -T on the shared object, you get for the -commands library:

00000000000aeab0  w   DF .text  0000000000000005  Base        V3DD::FLUSH_DRAWINGS()

For the normal libraries:

0000000000026990 g    DF .text  00000000000000f0  Base        V3DD::FLUSH_DRAWINGS()

Note the change from "w" to "g", which is said flag.

I currently wonder if the overloading of weak functions also works when dynamically loading the lib later manually as a plugin. That way, we could load the lib "on demand" (e.g. with an operation, or by config option), while it is disabled during normal startup.

I think that works, could break when unloading a library, though.

If this works, this could be a nice option for text logging, so you could load the "log_level_debug" plugin when you need debug text output, while when not loaded, no text output processing takes place at all (except probably evaluating the function, as i expect weak functions are not optimized out in order to work).

The function calls still happen, and you can actually do work in weak functions, they are no different to regular functions in that regard. I am not sure what would happen if the compiler decides to inline a weak function, or if they just don't do that.

[chhtz]

@planthaber @chhtz this time, this is probably worth a look by a second pair of eyes.

I can have a look later this week. I think it should be possible to provide some kind of unit-testing (e.g., provide sub-projects which link together different CUs which have been built with different flags).

[pierrewillenbrockdfki]

I can have a look later this week. I think it should be possible to provide some kind of unit-testing (e.g., provide sub-projects which link together different CUs which have been built with different flags).

Like this: https://github.com/rock-gui/gui-vizkit3d_debug_drawings/pull/15/files#diff-33394812ba204689144fd2f80832db83853ba1cb32403edb4e15fe4893e675fdR42

[chhtz]

Of course you did this already ^^ (I didn't have a closer look at the diff yet ...)

[chhtz]

Can't (easily) finish reviewing on Ubuntu24 (due to qt4 dependency)

[chhtz]

This should be at least 3.5 to avoid deprecation warnings.

[pierrewillenbrockdfki]

Hmm. Right, we don't really need to target anything older than Ubuntu 16.04(which is the first that comes with cmake 3.5). Thanks, will further change that.

[chhtz]

I guess in contrast to the qt4-qt5 branch this does not intent to support Ubuntu > 20.04 yet?

[pierrewillenbrockdfki]

That is correct, once this has been ironed out, i will move the qt4/qt5 branch accordingly.