f90wrap
f90wrap copied to clipboard
Clean up unit tests
- Make them all use a combination of CMake or Python's setup tools. This will ensure they compile with the correct compilers that match the Python distro being tested with. Avoid raw Makefiles.
- Make "nosetests" works.
I absolutely agree with the sentiment, but both distutils and numpy.distutils are messy for building mixed language projects, which is why I found raw Makefiles simplest initially. Haven't used CMake but depending on it seems like quite a lot of overhead.
I've build simple Python extensions with distutils and more complex mixed-language Python extensions with CMake. If you can get distutils to compile all your files --- for example, if the entire extension is in one source file --- then that is certainly the easiest. That seems to be the case with f90wrap, and I would see no reason to change. Thankfully, it looks like the mixed-language stuff is in the examples.
I've figured out how to build mixed-language extensions with CMake. Yes, it's a bit of overhead. But CMake is standardized, and that standardization allows users to compile your project the same as a dozen others. The example of how to do this is in:
https://github.com/citibob/fexception
This is a good example because it is multi-language (Fortran / Python / C++), while still being a very small project overall. And it has examples showing how to use it in each language. The scripts here should be transferrable to f90_wrap without too much trouble. (The fexception package might be of interest to f90_wrap users as well; it allows you throw exceptions in Fortran and catch them in Python. I use this to write Python unit tests for my Fortran code. I throw an exception deep within the Fortran code, and I'm then able to inspect and verify the state of the computation (in Python) at the point the exception was thrown).
When building CMake scripts, it might be useful to grab the C compiler from Python, rather than relying on the user to specify one (and hoping that it will be compatible with Python). This can be done as:
import sysconfig
sysconfig.get_config_var('CC') '/Users/rpfische/macports/gcc49-python3/bin/gcc-mp-4.9' sysconfig.get_config_var('CFLAGS') '-Wno-unused-result -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -pipe -Os -m64' sysconfig.get_config_var('CXXFLAGS') sysconfig.get_config_var('CXX') '/Users/rpfische/macports/gcc49-python3/bin/g++-mp-4.9' sysconfig.get_config_var('CXX_FLAGS')
(see for more: http://www.programcreek.com/python/example/66995/distutils.ccompiler.get_default_compiler )
HOWEVER... one must account for the possibility that the compiler used to compile Python is no loner available on the current system; thus, the user should still be able to override this mechanism.
-- Bob
On Wed, Oct 14, 2015 at 4:37 PM, James Kermode [email protected] wrote:
I absolutely agree with the sentiment, but both distutils and numpy.distutils are messy for building mixed language projects, which is why I found raw Makefiles simplest initially. Haven't used CMake but depending on it seems like quite a lot of overhead.
— Reply to this email directly or view it on GitHub https://github.com/jameskermode/f90wrap/issues/27#issuecomment-148190123 .
Thanks for the suggestions. Will consider CMake, and also look at conda which seems to be gaining a lot of traction in the scipy community at the moment.
also look at conda which seems to be gaining a lot of traction in the scipy community at the moment.
with conda, you have everything in hand.
A comment from a potential user that just discovered this project 10 minutes ago: I also find raw Makefiles perfectly fine :)