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. Johan > Martin > 28. jan. 2014 19:39 skrev "Garth N. Wells" <[email protected]> følgende: > > On 2014-01-28 18:26, Sean Farley wrote: >> >>> [email protected] writes: >>> >>> On 2014-01-27 15:41, Marie E. Rognes wrote: >>>> >>>>> On 01/08/2014 01:07 PM, Garth N. Wells wrote: >>>>> >>>>>> I'd suggest that FFC and UFC keep their own config/build systems (with >>>>>> the C code that crept into FFC being cleaned out), and have a >>>>>> top-level config/build script for installing both packages and running >>>>>> tests on both packages. >>>>>> >>>>>> With uflacs eventually being merged into FFC, that will leave us with: >>>>>> >>>>>> - UFL >>>>>> - FIAT >>>>>> - FFC + backends >>>>>> - Instant >>>>>> - DOLFIN >>>>>> >>>>> >>>>> The above sounds good to me. Any obstacles left? >>>>> >>>>> >>>> I'm wondering if there are any issues from a packaging perspective >>>> (Debian, MacPorts, etc) if FFC and UFC use different build/installation >>>> systems? If this is an issue, we could experiment with git subtree to >>>> bring FFC and UFC into one repo. My preference is still for a single >>>> 'project' as originally proposed. >>>> >>> >>> There shouldn't be any problem from a packaging perspective. For >>> example, in MacPorts a port can specify that it is obsolete and has been >>> replaced by another port. The obsolete port then gets deleted after >>> about a year or so. >>> >> >> My concern is not so much removing a package, but if a single package >> requires two different build systems, e.g. CMake and Python distutils. >> >> Garth >> _______________________________________________ >> 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
