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? -- 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
