instant is called by ffc, and also useful (and used) in other non-fenics contexts.
Martin On 8 January 2014 13:07, Garth N. Wells <[email protected]> wrote: > On 2014-01-08 11:33, David Ham wrote: > >> Hi all, >> >> Having discussed this around the Firedrake mob (except Florian who is >> still away), we don't have any objection to UFC going into FFC. >> Indeed, since our FFC branch does indeed have a non-UFC backend, it >> might even make us cleaner and move us towards the point at which we >> can start talking with you about merging our stuff into trunk. >> >> One small issue which will crop up is that FFC uses setuptools while >> UFC has a cmake build process. We would really like a combined package >> to be installable with setuptools (I don't expect this would cause any >> huge issues). >> >> > 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 > > Is Instant used by any projects/packages other than DOLFIN? If not, we > could keep the Instant repo for development and just copy instant/master > into DOLFIN when needed and not bother with Instant releases, leaving us in > terms of user packages and releases with: > > - UFL > - FIAT > - FFC + backends > - DOLFIN > > Four packages is lot better than where we were a year ago (which was 7). > > Garth > > We would be less happy about UFL going into FFC, as we think that >> breaks an important abstraction. We would be really, really unhappy >> about any of the above being merged with Dolfin, as that would give us >> a Dolfin dependency which is really non-trivial. However neither of >> those merges are being proposed right now, so I'm not sure we need to >> have that discussion now. >> >> Regards, >> >> David >> >> On 8 January 2014 08:03, Martin Sandve Alnæs <[email protected]> >> wrote: >> >> +1 to merging ufc into ffc. >>> >>> I'd rather not merge in ufl (yet). >>> >>> I plan to merge uflacs into ffc at a later date but not yet. >>> >>> It would be nice if we then split out the compiled stuff from ffc >>> into a separate python module and place all python modules from ufc >>> and ffc in a shared src/ or site-packages/ directory, as this makes >>> it easier to add to python path without installation for running >>> tests. >>> >>> Martin >>> 7. jan. 2014 23:23 skrev "Anders Logg" <[email protected]> følgende: >>> >>> On Tue, Jan 07, 2014 at 10:12:51PM +0000, Garth N. Wells wrote: >>>> >>>>> We’ve discussed over the past year consolidating FEniCS >>>>> >>>> packages. The motivations are: >>>> >>>>> >>>>> - Fewer packages for users to install >>>>> - Less confusion over dependency versions >>>>> - Simpler development and testing (fewer cross-package >>>>> >>>> dependencies and package tests that depend on other packages) >>>> >>>>> - Reduced burden of making releases (which will hopefully lead >>>>> >>>> to more frequent releases) >>>> >>>>> >>>>> Now that the first FEniCS release from git/Bitbucket has been >>>>> >>>> made, >>>> >>>>> I suggest that we start evolving towards consolidation (rather >>>>> >>>> than >>>> >>>>> taking any radical steps). As a first step, I propose that we >>>>> >>>> merge >>>> >>>>> FFC and UFC into one package. This doesn’t mean that FFC and >>>>> >>>> UFC are >>>> >>>>> suddenly deeply linked, but that UFC becomes one of the >>>>> >>>> implemented >>>> >>>>> FFC targets (and at first, the only). Longer term, having >>>>> backends/targets in FFC will make the addition of new >>>>> >>>> generation >>>> >>>>> targets easier to develop. >>>>> >>>>> Please respond with thoughts and opinions on merging FFC and >>>>> >>>> UFC! >>>> >>>> I'm very positive to this idea. >>>> >>>> I think UFL could also be merged into the same project. I know >>>> there >>>> will be objections to this from those who only use UFL (David Ham >>>> objected last time I suggested this), but still think it would be >>>> possible to resolve this by adding an option to only install UFL, >>>> something like >>>> >>>> cd ufl && sudo python setup.py install >>>> >>>> Another thing to consider is Debian/Ubuntu packages. I believe >>>> some >>>> work will be involved there as well (to apply for new packages >>>> and >>>> adjust dependencies), so perhaps it would not be optimal to make >>>> many >>>> "small" changes to the package organization? Or is it easy? >>>> Johannes >>>> can comment on this. >>>> >>>> -- >>>> Anders >>>> _______________________________________________ >>>> fenics mailing list >>>> [email protected] >>>> http://fenicsproject.org/mailman/listinfo/fenics [1] >>>> >>> >> -- >> >> Dr David Ham >> Departments of Mathematics and Computing >> Imperial College London >> >> http://www.imperial.ac.uk/people/david.ham [2] >> >> Links: >> ------ >> [1] http://fenicsproject.org/mailman/listinfo/fenics >> [2] http://www.imperial.ac.uk/people/david.ham >> >> >> _______________________________________________ >> fenics mailing list >> [email protected] >> http://fenicsproject.org/mailman/listinfo/fenics >> >
_______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
