fenics team mailing list archive

[Florian Rathgeber <florian.rathgeber@xxxxxxxxx>]

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

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.

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.

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

iEYEARECAAYFAlE2coYACgkQ8Z6llsctAxZdtgCff8zEchv/93iG1sPw4SwozXEv
fZEAoI1epCkvQL+Tct9+gQHbRdH6bMGN
=MqKY
-----END PGP SIGNATURE-----

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature