Subject: [UFC-dev] Module building utility

From: Martin Sandve Alnæs <[email-masked]>
Date: Fri, 20 Mar 2009 13:14:39 +0100

I'm in the process of updating SFC to use the build_ufc_module
function, and I have some remarks and a question.

First the question:

Why is "create_foo" %ignored? I was expecting something like
"%newobject create_foo" instead?

Then some remarks:

The arguments to build_ufc_module were not sufficient,
so I have removed some that were just passed on to instant
and added **kwargs to allow any arguments to instant.build_module.
This means FFC will need to update when I push my changes.

Before:

def build_ufc_module(signature, h_files,
                     cpp_files=None,
                     system_headers=None,
                     cpp_args=None,
                     cache_dir=None):

Now:

def build_ufc_module2(h_files, source_directory="",
system_headers=None, **kwargs):

"signature" is optional, passed in kwargs.

"cpp_files" is removed, use "sources" which is instant's argument name
for the same.

"cpp_args" is removed, use "cppargs" which is instant's argument name
for the same.

"cache_dir" is optional, passed in kwargs.

The source files may reside in a directory different from ".", given
by "source_directory".

Also, I'm currently generating code in a namespace "sfc", which this
script doesn't
handle. It's not very important, so I think I'll just drop the namespace.

Martin

---

From: Johan Hake <[email-masked]>
Date: Fri, 20 Mar 2009 14:02:13 +0100

> "%newobject create_foo" instead?

Good question!

In a previous edition I used %newobject.

The problem using any Foo objects from these functions in python is that they 
are all non shared_ptrs. The user can create all the ufc objects directly 
from the module and these are then all shared_ptr objects. I also had the 
imporession that these functions is only used by low level libraries.

That probably answers your question of why I did not used %newobject. If you 
need them you can probably just change %ignore with %newobject.

> "signature" is optional, passed in kwargs.

Ok.

> "cpp_files" is removed, use "sources" which is instant's argument name

Should it then be allowed to pass more sources to this function than h_files, 
i.e., should it be possible to hand source files that are not ufc 
implementations? If not should we include some sort of check for the passed 
source files, more than allready excists?

> "cpp_args" is removed, use "cppargs" which is instant's argument name

Ok.

> "cache_dir" is optional, passed in kwargs.

Ok.

> The source files may reside in a directory different from ".", given

The name changes are fine with me, but I think it makes sense to have named 
kwargs instead of the **kwargs. It's less error prone. 

> handle. It's not very important, so I think I'll just drop the namespace.

Ok, one could include an optional kwarg: cpp_namespace or something, which is 
attached before all strings in the derived_class list.

  if not cpp_namespace is None:
      derived_classes = ["%s::%s"%(cpp_namespace,der_class) for der_class in 
derived_classes ]

I think that should do the tricks.

Johan

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Fri, 20 Mar 2009 14:12:37 +0100

> need them you can probably just change %ignore with %newobject.

To use a pure UFC implementation in PyDOLFIN you need the create_foo
functions. But I tried to call them and it works fine. Haven't tested whether
they deallocate correctly though.

> source files, more than allready excists?

No, that's an invalid and completely unneccesary assumption, which I've removed.

> kwargs instead of the **kwargs. It's less error prone.

I agree in principle, but at least all the arguments used
and checked by build_ufc_module are named. It's less
maintenance work to just pass the rest through.

> I think that should do the tricks.

It works fine to remove the namespace from sfc code,
so lets not waste time on testing that.

Martin

---

From: Johan Hake <[email-masked]>
Date: Fri, 20 Mar 2009 14:31:39 +0100

On Friday 20 March 2009 14:12:37 Martin Sandve Alnæs wrote:
> > The problem using any Foo objects from these functions in python is that
> > they are all non shared_ptrs. The user can create all the ufc objects
> > directly from the module and these are then all shared_ptr objects. I
> > also had the imporession that these functions is only used by low level
> > libraries.
> >
> > That probably answers your question of why I did not used %newobject. If
> > you need them you can probably just change %ignore with %newobject.
>
> functions. But I tried to call them and it works fine. Haven't tested
> whether they deallocate correctly though.

Ok, so this means that the %ignores does not kick in?

> > Should it then be allowed to pass more sources to this function than
> > h_files, i.e., should it be possible to hand source files that are not
> > ufc implementations? If not should we include some sort of check for the
> > passed source files, more than allready excists?
>

You mean that it is unneccesary to assume that a user can pass other files? If 
so, fine with me.

> > The name changes are fine with me, but I think it makes sense to have
> > named kwargs instead of the **kwargs. It's less error prone.
>

Ok. Should we check that the user does not pass kwarg to instant that will not 
make sence for example: additional_declarations.

> > Ok, one could include an optional kwarg: cpp_namespace or something,
> > which is attached before all strings in the derived_class list.
> >
> >      derived_classes = ["%s::%s"%(cpp_namespace,der_class) for der_class
> > in derived_classes ]
> >

Ok.

Johan

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Fri, 20 Mar 2009 14:51:13 +0100

> Ok, so this means that the %ignores does not kick in?

This may be an effect of other modules without the %ignores, don't know.

> You mean that it is unneccesary to assume that a user can pass other files? If

I mean that it is unneccesary to assume _anything_ about those files.
If I want one .cpp file and ten headers or the other way around, no problem.
Why should there be a restriction?

> make sence for example: additional_declarations.

No need, it will trigger an error when instant.build_module is called.

Martin

---

From: Johan Hake <[email-masked]>
Date: Fri, 20 Mar 2009 15:19:51 +0100

On Friday 20 March 2009 14:51:13 Martin Sandve Alnæs wrote:
> >> > The problem using any Foo objects from these functions in python is
> >> > that they are all non shared_ptrs. The user can create all the ufc
> >> > objects directly from the module and these are then all shared_ptr
> >> > objects. I also had the imporession that these functions is only used
> >> > by low level libraries.
> >> >
> >> > That probably answers your question of why I did not used %newobject.
> >> > If you need them you can probably just change %ignore with %newobject.
> >>

I think it was the base class create_foo that was called. Also it did indeed 
return a shared_ptr<ufc::foo> so I just removed the %ignore statements.

> >> >> "cpp_files" is removed, use "sources" which is instant's argument
> >> >> name for the same.
> >> >
> >> > ufc implementations? If not should we include some sort of check for
> >> > the passed source files, more than allready excists?
> >>
> > You mean that it is unneccesary to assume that a user can pass other
> > files? If so, fine with me.
>
> If I want one .cpp file and ten headers or the other way around, no
> problem. Why should there be a restriction?

Ok.

> > Ok. Should we check that the user does not pass kwarg to instant that
> > will not make sence for example: additional_declarations.
>

Ok.

Johan