dolfin team mailing list archive

[Johan Hake <hake.dev@xxxxxxxxx>]

Marco!

This is caused by the new automatic parsing of dependencies for
compiled_modules in Python. It was added so a minimum of dependencies
are dragged into the compilation, reducing the compilation time
considerably. If you instead of #including "dolfin.h" only #include
"dolfin/fem/GenericDofMap.h", the compilation time was almost halved on
my laptop.

Unfortunately it is only the public interface which get parsed and
included in dependency generation. This means that #include statements
for GenericDofMap is not generated. It has to be manually included...
Because of the nice speedups for the compilation time I am inclined to
keep the somewhat flawed automatic dependencies checks we have now.

I do agree that your case should be supported in a better way than
adding it as a hack, as you did. Another hack is to introduce a dummy
public dependency:

class Delta1 : public Expression
{
public:

  GenericDofMap* dummy;

  Delta1() : Expression() {}
...

which is also sub optimal as it is non-intuitive.

What we probably need is to expose some more compile options to the
Expression interface so you can do:

  Expression(cppcode_d1, element=DGe, \
             system_headers=["dolfin/fem/GenericDofMap.h"])

Other opinions?

Johan

On 09/03/2012 03:47 PM, Marco Morandini wrote:
> The attached code used to work.
> Now I have to explicitly inlcude dolfin.h, because GenericDofMap.h
> is not included in the generated code.
> 
> The workaround I've found is simple, but it is at the same time it is
> somewhat counter-intuitive: the expression code get wrapped inside the
> namespace "dolfin", that must be closed before including "dolfin.h", and
> then reopened.
> 
> Marco
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp
>