On Wednesday, January 8, 2014, Martin Sandve Alnæs wrote:
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] [1]
