On 2014-01-29 13:42, Johan Hake wrote:
On Wed, Jan 29, 2014 at 10:44 AM, Garth N. Wells <[email protected]>
wrote:
On 2014-01-29 09:35, Johan Hake wrote:
On Wed, Jan 29, 2014 at 9:52 AM, Garth N. Wells <[email protected]>
wrote:
On 2014-01-28 21:06, Anders Logg wrote:
On Tue, Jan 28, 2014 at 08:33:38PM +0100, Johan Hake wrote:
On Tue, Jan 28, 2014 at 8:24 PM, Martin Sandve Alnæs
<[email protected]>
wrote:
What if we move ufc.h to dolfin? Keeping the ufcutils module
in ffc. Then
we can maybe write a test that checks if a given ffc
generates ufc code
that implements the ufc interface of a given dolfin.
Sounds like a good idea! Then we could incorporate the CMake
configure process
into DOLFIN CMake. We have also loosely talked about removing UFC
and
eventually generate DOLFIN code, which resonates with moving UFC to
DOLFIN.
I am not convinced this is a good idea:
I'm not convinced either - doesn't seem like a natural split. How
about:
1. We try letting distutils take care of building the SWIG
wrappers
in place of CMake:
http://docs.python.org/2/distutils/setupscript.html#extension-source-files
[1]
[2]
or;
This was the case before we added shared_ptr to ufc. Then we
decided
to add boost and a proper configure system was needed for that. Not
sure we want to go back to distutils.
Maybe we should switch to std::shared_ptr, in which case we won't
need Boost and compilation will be easy.
Yes but logic wrt what namespace that should be used needs to be
included std::tr1:: or just std::, that might be trivial but the
amount of configuration that can be done for the extension module is
very limited in distutils.
I'd advocate for using std::shared_ptr. It's been in gcc since 4.3
(March 2008) and is available for all the major compilers.
Garth
One option could be to hide the CMake logic within the setup.py
file.
We could define special build target for ufc configuration and
compilation and passsing the arguments to a cmake call. It sounds
doable but could probably be quite convoluted...
2. UFC just provides the SWIG .i files, and lets the library
wanting
the SWIG wrappers do the compilation?
It is somewhat strange to let another library generate a python
extension module.
It will compile the module - the interface code will be in UFC.
Yes, I see that. Should dolfin also be responsible to compile the
extension modules? That is now done in ufc/utils/build.py.
Johan
Garth
Johan
Garth
+ Only DOLFIN uses ufc.h anyway
+ Simplifies build system(s)
+ More flexibility when changing the code generation interface
- No clear versioning that tells us which interface FFC and
DOLFIN
talk through
- UFC was once introduced to solve a problem we had which was
that
changes were often made to both FFC and DOLFIN and users
needed
to know which version matched.
--
Anders
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics [2] [1]
Links:
------
[1] http://fenicsproject.org/mailman/listinfo/fenics [2]
[2]
http://docs.python.org/2/distutils/setupscript.html#extension-source-files
[1]
Links:
------
[1]
http://docs.python.org/2/distutils/setupscript.html#extension-source-files
[2] http://fenicsproject.org/mailman/listinfo/fenics
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
