Add an option for py-numpy to link against openblas.

[demon]

Summary

This patch adds an ability to link against openblas library instead of lapack/atlas.
Most of the work done by Eijiro Shibusawa <[e-mail]>, the maintainer of openblas port. I only tweaked OPTIONS stuff.

[demon]

This is an updated patch from the author.

[thierry]

`make configure' produces an error with ATLAS:

cc _configtest.o -L/usr/local/lib -lptf77blas -lptcblas -o _configtest
/usr/bin/ld: undefined reference to symbol `ATL_buildinfo' (try adding -latlas)
usr/local/lib/libatlas.so.2: could not read symbols: Bad value
cc: error: linker command failed with exit code 1 (use -v to see invocation)
/usr/bin/ld: undefined reference to symbol `ATL_buildinfo' (try adding -latlas)
usr/local/lib/libatlas.so.2: could not read symbols: Bad value
cc: error: linker command failed with exit code 1 (use -v to see invocation)
failure.

but anyway, make continues, and everything seems fine.

No default is pre-selected for BLASLIB, but BLAS is choosen, and that's fine.

An other error is produced by configure with BLAS:

cc _configtest.o -L/usr/local/lib -lblas -o _configtest
_configtest.o: In function `main':
_configtest.c:(.text+0x5): undefined reference to `ATL_buildinfo'
usr/local/lib/gcc48/libgfortran.so.3: undefined reference to `getf2@GCC_4.6.0'
usr/local/lib/gcc48/libgfortran.so.3: undefined reference to `floatunditf@GCC_4.6.0'
//usr/local/lib/gcc48/libgfortran.so.3: undefined reference to `__subtf3@GCC_4.6.0'
...

but I have not yet found a clean way to make it honor LDFLAGS, and anyway, this is better that the actual situation!

[demon]

Okay, I updated the patch to use OPTIONS_SINGLE instead of OPTIONS_RADIO (to enforce user to select at least one library), made BLAS the default and switched to USES=blaslapack framework.

Is it OK?

[demon]

And one more thing: does numpy really need py-nose in RUN_DEPENDS?

As far as I understand it is needed only to run test suite, if I am right, may be we hide this dependency under new OPTION?

[koobs]

Check setup.py.

If nose is declared as a tests_require, then it doesn't need to be in RUN_DEPENDS. If its listed in install_requires, I'd still be dubious.

For tests in my ports I do:

TEST_DEPENDS= foo \
              bar

OPTIONS_DEFINE=TESTS

TESTS_DESC=Install test suite requirements
TESTS_BUILD_DEPENDS=${TEST_DEPENDS}

regression-test: build
   cd ${WRKSRC} && ${PYTHON_CMD} ${PYDISTUTILS_SETUP} test

[demon]

There is neither tests_depends nor install_depends in setup.py, but I grepped the sources and nose is mentioned only in .../test/... or .../testing/... subdirectories.

So I also plan to adopt the patch you propose to hide py-nose dependency under TESTS OPTION.

[koobs]

@demon ping

[koobs]

Pending changes to remove nose

[koobs]

This revision was open and the last comment mentioned that further changes were necessary. I was unaware that it had been committed, so updated the status so that it was blocked on me.

Since this was committed in rP382547 but the Differential Revision: line did not contain a full URL, Phabricator did not automatically close the review.

Closing revision now as it complete.