fenics team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

I don't see a reason for separating the installs of FFC and UFC. One cannot
be used without the other.

--
Anders



On 7 March 2013 09:26, Johan Hake <hake.dev@xxxxxxxxx> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 03/06/2013 11:44 AM, Florian Rathgeber wrote:
> >
> >
> > On 06/03/13 07:17, Johan Hake wrote:
> >> On 03/05/2013 11:32 PM, Florian Rathgeber wrote:
> >>> On 27/02/13 21:46, Anders Logg wrote:
> >>>> On Wed, Feb 27, 2013 at 10:13:17PM +0100, Johan Hake wrote:
> >>>>> On 02/27/2013 09:54 PM, Garth N. Wells wrote:
> >>>>>>
> >>>>>> On Tuesday, 26 February 2013, Anders Logg wrote:
> >>>>>>
> >>>>>> On Tue, Feb 26, 2013 at 10:57:12AM +0100, Martin Sandve
> >>>>>> Alnæs wrote:
> >>>>>>> On 26 February 2013 10:07, Garth N. Wells
> >>>>>>> <gnw20@xxxxxxxxx
> >>>>>> <javascript:;>> wrote:
> >>>>>>>
> >>>>>>>> On 26 February 2013 01:16, Anders Logg
> >>>>>>>> <logg@xxxxxxxxx
> >>>>>> <javascript:;>> wrote:
> >>>>>>>>> On Mon, Feb 25, 2013 at 10:13:44AM +0100, Martin
> >>>>>>>>> Sandve Alnæs
> >>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> - I think the two-way split (keeping dolfin
> >>>>>>>>> separate, joining
> >>>>>> at least
> >>>>>>>>>> ufc-ffc-ufl) sounds most compelling and carries
> >>>>>>>>>> less risk.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Even more granular would be ufc-ffc. That way, FFC
> >>>>>>>> would contain all the code formatting.
> >>>>>>>>
> >>>>>>>>> I'm still tempted by having one big repo.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> I'm inclined to stay close to the status quo. If a
> >>>>>>>> big repo is contemplated, someone should make one and
> >>>>>>>> we can test if it's
> >>>>>> workable
> >>>>>>>> with bzr. It may just be too big and bzr too slow.
> >>>>>>>
> >>>>>>>
> >>>>>>> The best way to do such things is usually gradually.
> >>>>>>> The first
> >>>>>> steps could
> >>>>>>> be: 1) Move ufc into the ffc repo. 2) Move dolfin
> >>>>>>> wrapper generation back from dolfin to ffc? In these
> >>>>>>> cases there are no big history and patching issues, so
> >>>>>>> this can be done soon with no issues whatsoever (but
> >>>>>>> preferably after we merge the work in progress by
> >>>>>>> Anders and I).
> >>>>>>
> >>>>>> Sounds like a good start. Any objections to this?
> >>>>>>
> >>>>>> No.
> >>>>>>
> >>>>>> Does this need we need to use CMake for FFC?
> >>>>>>
> >>>>>> I do like the simplicity of the Python install for FFC
> >>>>>> over CMake.
> >>>>>
> >>>>> If we are going to keep each project in different sub
> >>>>> directories we can keep distutils for ffc.
> >>>>>
> >>>>> ffc/ ffc/ setup.py ... ufc/ CMakeList.txt ...
> >
> >>>> Sounds like a simple solution, but we also need a top level
> >>>> installation method. Should that be CMake or distutils?
> >
> >>> Why not support both (as PETSc does)? A top level
> >>> CMakeLists.txt descends in both the ffc subdirectory (calling
> >>> distutils as e.g. described in this blog post:
> >>> http://bloerg.net/2012/11/10/cmake-and-distutils.html) and ufc
> >>> subdirectory.
> >
> >> This could be done, but we need the CMake for the the UFC
> >> extention module configuration, which generates a Python module.
> >> Your example above does not cover that case. As I understand it
> >> it is rather the other way around: distutils need to call CMake.
> >
> > For using CMake as the top-level build method I don't think there
> > are many changes needed for the UFC build: CMake descends into the
> > subdirectory and calls the UFC CMakeLists.txt.
>
> Agree. This is not a problem.
>
> >>> I think it's really important that FEniCS components are also
> >>> distutils/pip-installable so you can require them as
> >>> dependencies in other Python packages. That's what we would
> >>> need for PyOP2, but it currently falls over because UFC has no
> >>> distutils installation path.
> >
> >> Correct me if I am wrong, for pip-install to work we need a top
> >> level distutils script? If so that script can install the ffc
> >> and python components of ufc (when we have merged fcc and ufc).
> >> That same script need to trigger the configure part of CMake and
> >> either wait for it to finish (some popen logic maybe?). Then
> >> either let CMake install everything or just the .h files or let
> >> distutils install everything once the extension module is
> >> generated.
> >
> > Yes, distutils requires a top level setup.py/setup.cfg. This could
> > simply depend on FFC and UFC and they could provide their own
> > setup.py.
>
> Letting the toplevel setup.py call ffc's and ufc's setup.py?
>
> Would that be necessary? My impression is that ffc and ufc will be
> merged as one package. We could add some logic for not installing, let
> say ufc, but that can be included as options in the toplevel script
> without adding two setup.py script for each of ufc and ffc.
>
> > For UFC I think both options you describe would work. The only
> > tricky part I think is passing options given to setup.py to CMake
> > in a sensible way i.e. --prefix should become CMAKE_INSTALL_PREFIX.
> > Maybe also read an environment variable like UFC_CONFIGURE_OPTIONS
> > and pass this to CMake as a raw argument string.
>
> Yes that would need to be figured out, but it should not be that hard.
>
> > I've looked for examples other than PETSc doing this but haven't
> > really found any so far. And PETSc's way is too elaborate for this
> > use case.
>
> Yes, I think so too.
>
> Johan
>
> > Florian
> >
> >> Johan
> >
> >>> Florian
> >
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJROE8XAAoJEEzjkVbXgH+MOpQH/i8/YY0fWs6iC0GLpYqHcrG0
> nUB+yUFbWkfQvePNH0yE9v/QC5if9X5w0drkmeYbF6mVsC+VUWmoN21Jc2tCWulA
> BYZ3/eUvFuk89BkPZmwD/mSo3yOiOHW0J3jog1x45gwUdVuKjoksFZO4p/B699gd
> biE6xZfz2aFyxY9B7NYPscKO1u/6ANE/kshkMPu/4sjYW5pzBSAtallKLx7pygHl
> 2GsoQNaGHxrhdo2FAGL+k2G87/+QYuI8lwiAb1E1wqKjqi3JbHDoJv+uoM6N5+Rz
> 23H9Rf2PTsux/8vh/6Dg7hDQ8DaaVNoAzxfKY3HuR2ZSB2CnkTL3h0EIdNLJCXs=
> =nw6q
> -----END PGP SIGNATURE-----
>