SWIG < 3.0.10 compatibility

[Jan Blechta]

See https://bitbucket.org/fenics-project/dolfin/pull-requests/339/use-doxygen-to-validate-c-documentation-in/activity#comment-33228593.

[Prof Garth Wells]

Seems rather subtle; it works fine for me with Swig 3.0.8 and 3.0.12.

Should we bump the required version to 3.0.12 since that's what we're testing with?

[Jan Blechta]

Did you try without building docs?

What I specifically wanted to look into is how is the business with division operators, whether they work as expected.

I don't think we need to bump it. We still have reasonable coverage by building on legacy systems like mine is

[Prof Garth Wells]

@blechta I tried building without doxygen (which is what failed for me previously). I didn't run any tests.

[Martin Sandve Alnæs]

It's nice to keep 3.0.8 compatibility, it's the version in Ubuntu 16.03 LTS.

[Prof Garth Wells]

Problem is testing, especially if it's like Swiss cheese - old and new work, but some in between don't.

[Jan Blechta]

I agree, that's why I wanted to have a look on this deeper, understand the problem and come up with a reasonable suggestion, which might might be "let's bump".

[Jan Blechta]

Issue #832 was marked as a duplicate of this issue.

[Jan Blechta]

Now understand a mechanism of the bug. A wrapper code without doxygen

class Klass(object):
    __truediv__ = __div__ # our extension
Klass.__div__ = ... # Some SWIG magic

can't work. While with doxygen

class Klass(object):
    def __div__(self, *args): # This is how SWIG stores docstring
        """__div__ docstring"""
        return _module.Klass___div__(self, *args) # dummy return
    __truediv__ = __div__ # our extension
Klass.__div__ = ... # Some SWIG magic

works. The difference between SWIG 3.0.8, 3.0.10 and 3.0.13 is whether any of __div__, __truediv__ are generated, causing different failure conditions.

[Tormod Landet]

In that case this is very much related to #830 and can be fixed by giving all functions and methods empty docstrings by default and let doxygen overwrite them if available. I have still not had time to look further into the feasibility of that, though

[Jan Blechta]

I have the fix for this issue https://bitbucket.org/fenics-project/dolfin/branch/jan/fix-issue-828#diff independent of docstrings presence. So let me look on #830 too.

But maybe the approach of generating empty docstrings is not a bad idea. It could assure that the equivalent C++ is generated in both cases.

[Jan Blechta]

fccbabe7b0ffec57f2976f9d776ecb70e58c6858