If you do decide to put ufc into dolfin, please, please make ufc an optional dependency of ffc. We have ffc branches targetting things other than ufc and it would be a really severe imposition if we suddenly acquired a dolfin dependency.
Regards, David On 29 January 2014 09:35, Johan Hake <[email protected]> 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 >> >> 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. > > 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. > > 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 >>> >> > -- Dr David Ham Departments of Mathematics and Computing Imperial College London http://www.imperial.ac.uk/people/david.ham
_______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
