On 2014-01-29 14:20, Anders Logg wrote:
On Wed, Jan 29, 2014 at 02:18:08PM +0000, Garth N. Wells wrote:
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.
You mean a switch to std::shared_ptr throughout DOLFIN?
Yes.
Are there any important-to-support systems on which this would be a
problem? All the systems I use have good support for std::shared_ptr.
Garth
--
Anders
>>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.
>>
>
> 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
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
