fenics team mailing list archive

[Johan Hake <hake.dev@xxxxxxxxx>]

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