fenics team mailing list archive

[Florian Rathgeber <florian.rathgeber@xxxxxxxxx>]

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



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.

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

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.

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.

Florian

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

iEYEARECAAYFAlE3HfcACgkQ8Z6llsctAxbQdQCgxVmxG0Z8eCop50Bnpc9xgcIG
fZsAoLyrIrs2/3c8fdNPJZJ1P33puMPj
=wBji
-----END PGP SIGNATURE-----

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