fenics team mailing list archive

[Johan Hake <hake.dev@xxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

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

Johan

> Florian
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRNu2BAAoJEEzjkVbXgH+Ms8UH/jB77gMNQaicem7jpQkFeB23
eNWZd+s/PMqdPd8AMzrem3lDbsyoxZg9ocYrJdCsUKC06rYQJhBbC/6T6lKh2qmZ
dpb/5SRXCE4Sxl6qN3Kx0hHpQ4zouEODU/G7XZQpA3tgEr3Miw3OmaDxk9zDGPOK
nDcyClxJErgeCIeBMj8ie+GPcB1zic/njm06gZ9QZy1gLS7XtOBVF8ZOIjb59xlJ
CS0XJt5tZUSyMc06hpQBp01a8uT+E5YqtrKZr5kDM/a6JnxXtd5Y1Y1WOkwcdDV2
uxNjyMnDxgAAgmKDm/I1KYbYqbEJNykdxFynQominTN+J4gukp7K/s1D36iYcI8=
=Svgq
-----END PGP SIGNATURE-----