-----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 >>>>>> <[email protected] >>>>> <javascript:;>> wrote: >>>>>> >>>>>>> On 26 February 2013 01:16, Anders Logg <[email protected] >>>>> <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-----
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Mailing list: https://launchpad.net/~fenics Post to : [email protected] Unsubscribe : https://launchpad.net/~fenics More help : https://help.launchpad.net/ListHelp
