add cmake macro/function to detect undefined references

[ftalbrecht]

I ran across undefined references in Python bindings, which are extremely hard to find and debug, since they are only detected on module import (and not easy to debug if a module import fails within the import of another module). I got those undefined references quite often, since there is a problem with some compilers to put default ctors into libs. I can detect these errors with something like:

nm -Cu LIB_OR_SO_IN_QUESTION | grep Dune

It would be nice to have such a check within a cmake macro or function, to be able to trigger a build failure; in that case the output of the above command is a good hint where to start looking for the error.

This is thus a reminder for me (or anyone willing) to add such a macro/function...

[renefritze]

So basically you want a build target that filters each generated DSO's symbol table for 'Dune'? Something like

make check_my_so
Dune::FOO
Dune::BAR

make check_your_so
Dune::FOO

And 'Dune' would (somehow?) be input for that filter macro?

[ftalbrecht]

Roughly, yes. For each bindings target foo, I would like to have something like

make check_foo_is_importable

• The generic way to check that would be to python -c "import bindings", which was not doable in the old setup (with the correct python from the correct virtualenv).
• Another way to check importability would be to check for undefined references that start with Dune (see my original comment above). In general, there may be undefined references outside of Dune (which we have no control over), but within Dune, there should be none. In this case, the Dune could be hardcoded.

Once we have such targets (and once bindings compile in finite time and memory), it would be nice to collect them in some

make check_bindings_are_importable

taget which could then also be executed on tavis as a first test-but-not-really-a-test check of the bindings. Thus it could make sense to hook the generation of such a target into the bindings generation cmake function in dune-pybindxi...

[renefritze]

Oh, if you want to check if a generated module is importable just call make pytest. That's already done in travis too. See https://github.com/dune-community/dune-xt-common/blob/master/python/test/base.py

[renefritze]

Correction: it's make test_python: https://github.com/dune-community/dune-xt-super/blob/master/.ci/templates/dune-xt-docker/test_python.bash.in

[ftalbrecht]

K, nice. Then I guess this is resolved! Two questions remain, however:

• in https://github.com/dune-community/dune-xt-common/blob/master/python/test/base.py#L3, does the import work if some other submodule is broken (e.g., dune.xt.common.foo is not importable).
• in https://github.com/dune-community/dune-xt-common/blob/master/python/test/base.py#L8 importing all submodules of dune.xt.common is tested. It looks to mee that when I call this from another module, say dune-xt-la, it will still only test importability of dune.xt.common, not dune.xt.la.

[renefritze]

1. xt-common is actually somewhat special there indeed. The linked import necessarily imports the bindings currently. If those are broken, the travis test itself will then still fail because test discovery errors out before test execution.
2. That's module specific code: https://github.com/dune-community/dune-xt-la/blob/master/python/test/base.py#L8

[ftalbrecht]

Thx fo the clarification. So we can close this?

[renefritze]

Yes