On 2014-01-29 14:49, Martin Sandve Alnæs wrote:
Just so we know what we're discussing here: What do you mean by 'good
support'?
That reasonably recent compilers (i.e. compilers available on a well
maintained systems) from the major vendors (GCC/Clang/Intel/IBM) support
it.
It's not in the C++03 standard, so to get it we will need to enable
C++11.
Yes.
Garth
This does not compile with gcc 4.4.7 on our cluster unless passing
-std=c++0x:
#include <memory>
int main()
{
std::shared_ptr<int> p;
return 0;
}
Martin
On 29 January 2014 15:36, Garth N. Wells <[email protected]> wrote:
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]
[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]
[2]
http://docs.python.org/2/distutils/setupscript.html#extension-source-files
[1]
[1]
Links:
------
[1]
http://docs.python.org/2/distutils/setupscript.html#extension-source-files
[1]
[2] http://fenicsproject.org/mailman/listinfo/fenics [2]
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics [2]
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics [2]
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
