A quick test of Martin's mini program on NERSC. Results: Intel 14.0.0.080: Compiles fine with -std=c++0x GCC 4.8.2: Compiles fine with -std=c++0x Cray 8.2.2: No idea what the C++11 flag is. PGI 13.6-0: No support. <http://www.pgroup.com/doc/pgiug.pdf> PathScale 4.0.12.1: No support. <http://www.pathscale.com/ekopath-user-guide>
The last two compilers are dropped from the latest machine (Edison), so I guess they are considered unsuitable anyways. Not sure about Cray's own suite. --Nico On Wed, Jan 29, 2014 at 3:49 PM, Martin Sandve Alnæs <[email protected]> wrote: > Just so we know what we're discussing here: What do you mean by 'good > support'? > > It's not in the C++03 standard, so to get it we will need to enable C++11. > > 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] >>>> >>[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 > > > > _______________________________________________ > fenics mailing list > [email protected] > http://fenicsproject.org/mailman/listinfo/fenics > _______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
