dolfin team mailing list archive

[Ola Skavhaug <skavhaug@xxxxxxxxx>]

Kent-Andre Mardal skrev den 21/08-2008 følgende:
> 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 ? 

That's not clear to me. Probably, this is true in many cases.

Ola
 
> Kent 
>