dolfin team mailing list archive

[Kent-Andre Mardal <kent-and@xxxxxxxxx>]

On to., 2008-08-21 at 09:53 +0200, Ola Skavhaug wrote:
> kent-and@xxxxxxxxx skrev den 20/08-2008 følgende:
> > > On Wednesday 20 August 2008 13:17:20 Garth N. Wells wrote:
> > >> Garth N. Wells wrote:
> > >> > Is it easy to modularise pyDOLFIN so that we generate multiple smaller
> > >> > wrapper code files? It's getting really tedious to compile
> > >> > dolfin_wrap.cc.
> > >>
> > >> Can anyone add anything on this? It's really annoying me.
> > >
> > > We do that in PyCC, so simula scons should be able to handle it. But I
> > > understand that it brings more hassle than it solves. Ola and Martin could
> > > probably elaborate on these issues.
> > >
> > > This has also been discussed previously see for example the late part of
> > > the
> > > thread:
> > >
> > > <http://www.fenics.org/pipermail/dolfin-dev/2008-March/006935.html>
> > >
> > > Johan
> > >
> > >
> > 
> > It is annoying.
> > 
> > One can break up the interface file in several interface files. The problem
> > with this is that types defined in one interface file are often used in other
> > interface files and here the attributes of these types are not known.
> > The 'import' statement in SWIG is suppose to solve this, but last
> > I tried I had problems.
> 
> You would need to import the SWIG interface file to get the type information
> correct. For instance, if we split up the SWIG interface files in as many
> Python modules as we have "dolfin modules":
> 
> cd dolfin
> declare -i num_modules
> num_modules=`tree -i -d -L 1 --noreport | wc -l`-1
> echo "The number of sub-modules in dolfin is $num_modules"
> 
> 
> For instance, if we need the type info from the graph module in the mesh
> module, we would need to do:
> 
> // File e.g. mesh.i
> 
> %import path/to/graph.i
> 
> The problem now is that SWIG may use a lot of time parsing all the iterface
> files several times and generating the same type information over and over
> again.
> 
> Ola

But if one updates one headerfile then I guess only the module that
includes this header will need new wrapper code and compilation ? 

Kent