[email protected] writes: > 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.
Ah, yes, that is a bit of a rough spot. If there are two build systems then I'd have to do a little manual work but it shouldn't be too bad. _______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
