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