dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Sun, Apr 15, 2007 at 01:29:20AM +0200, Johan Jansson wrote:
> > I have modified the way PyDOLFIN includes the interface files in
> > dolfin.i. There is now a line
> >
> >     %include "dolfin_headers.h"
> >
> > The file dolfin_headers.h is generated using the script generate.py
> > which extracts all the dolfin headers from all the dolfin_foo.h files
> > under src/kernel. This should mean that we don't need to give the
> > -includeall flag to SWIG.
> >
> > Johan, could you take a look at this and see if it looks like a good
> > idea?
> >
> > /Anders
> 
> One advantage of the -includeall method is that it includes the headers in
> the correct order (in the dependency order). I have to go back and check
> how important this really is, but as far as I remember this was a
> necessary condition for generating the interface properly. But perhaps
> it's simple to generate the list in the correct order.
> 
> The advantage with a generated header list is that it gives much more
> control of what to include/exclude, so I agree that it's desirable.
> 
>   Johan

ok, good.

If you look at the generated dolfin_headers.h, there seem to be
quite a lot of headers in there that should not be needed in the
Python interface. For example:

%include "dolfin/MonoAdaptiveFixedPointSolver.h"
%include "dolfin/MonoAdaptiveJacobian.h"
%include "dolfin/MonoAdaptiveNewtonSolver.h"
%include "dolfin/MonoAdaptiveTimeSlab.h"
%include "dolfin/MonoAdaptivity.h"

just to name a few.

How about the following convention. There are three kinds of header
files in DOLFIN.

1. Header files that should be available in the user interface (both
DOLFIN and PyDOLFIN). These are things like Mesh, Vector, Matrix.

2. Header files that should be available to other kernel modules.
These are things like DiscreteFunction which is included in
XMLFile.cpp but is not intended for general use.

3. Header files that are private to a kernel module. These are things
like all the pre-generated elements in src/kernel/elements which are
only included by .cpp files in that module.

Header files of type 1 should be placed under foo/dolfin/ and included
in dolfin_foo.h. This way, they will get included in dolfin.h *and*
PyDOLFIN (picked up by generate.py from the dolfin_foo.h files).

Header files of type 2 should be placed under foo/dolfin/ but *not*
included in dolfin_foo.h. This way, they will not be included in
dolfin.h nor PyDOLFIN, but they will be available by

    #include <dolfin/Foo.h>

both from within DOLFIN and for a user of the C++ library.

Header files of type 3 should just be placed under foo. This way, they
will only be accessible to the module they are placed under.

If we get this working, DOLFIN and PyDOLFIN would essentially have the
same interface and we would minimize the number of classes we need to
document and also minimize compile time for compiling PyDOLFIN which
now takes some time to build.

/Anders