Clean up unit tests

[citibeth]

1. 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.
2. Make "nosetests" works.

[jameskermode]

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.

[citibeth]

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 notifications@github.com
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
#27 (comment)
.

[jameskermode]

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.

[hainm]

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.

[astrojuanlu]

A comment from a potential user that just discovered this project 10 minutes ago: I also find raw Makefiles perfectly fine :)