Openblas detection and test

[miroi]

let us see if the CI test will pass...

[miroi]

current problem is that libopenblas packages are not behaving well on testing virtual servers, have to find out more ...

[miroi]

see also http://stackoverflow.com/questions/37545919/libopenblas-for-travis-ci-mixing-blas-lapack-atlas-openblas

[miroi]

ah, I see no openblas package for osx, suggesting to skip this test for OSX

[miroi]

Finally I got tests green ! Ready for merge.

[miroi]

well, the 'bloody' part of this change was playing with travis-ci configurations, to see, which packages go well with the 'offending 'libopenblas package.

[bast]

Thanks! However, I don't think the code duplication with the separate test script is necessary and good. Either the code needs to be generalized back into one file or the code duplication be abstracted into a module. We definitely want to avoid code repetition. D.R.Y.

[miroi]

what is "D.R.Y." ?

ah, I found it , it means don't repeat yourself (DRY)

[bast]

I cannot integrate this as a PR. There is code repetition (test_openblas.py contains code that is repeated in test.py). Also we cannot just copy-paste CMake code from other projects without proper attribution. I will pull this into a branch and clean it up there. Also tests fail and I don't know why. Need to look at it.

[miroi]

hi, at least please try to restart tests, and see if they pass;

ad: test_openblas.py - I need another mixture of packages, this is how they advised it from travis

sorry for not putting proper reference to the module's source; but can we modify it ?

[bast]

We can modify the source (BSD license) but we must attribute/acknowledge the source. Also I have restarted tests and they still fail for some mysterious reason. I will pull this into my fork and then close the PR and clean it up there. But thanks for the work on this.

[miroi]

Hi, libopenblas package somehow hurts composition of packages, if you get rid of it, tests should pass. But I would try some newest linux platform in travis-ci to see what openblas hurts/does not hurt.

[bast]

I have cleaned up your code on the openblas branch in the central repo but the OpenBLAS test still fails: https://travis-ci.org/coderefinery/autocmake/builds/143905558. Can you please have a look why it fails? Otherwise I cannot integrate it.

[bast]

If the code works on your computer but fails on Travis for some reason that we cannot solve, we could also get rid of the test. The code will get tested by the community and if there are issues, we react.

[miroi]

It seems that travis-ci is not able to set up healthy virtual testing servers;

here it hangs on (long) boost test

To cope with this I would set up another testing server, let say circle-ci, and see.

test/test.py::test_boost_libs 
No output has been received in the last 10 minutes, this potentially indicates a stalled build or something wrong with the build itself.
The build has been terminated

[bast]

I am happy with Travis and do not want to add another CI service since this will increase complexity and IMO add little benefit. If the Boost test turns out to be a problem, we can always remove the test.

[miroi]

Well, openblas test

https://travis-ci.org/coderefinery/autocmake/builds/135607059

depends how travis-ci 'pre-cooks' the virtual server with the openblas package:

https://github.com/coderefinery/autocmake/blob/openblas/.travis.yml#L70

This is the case where we don't have control on how non-native packages will behave....

[miroi]

Xianyi is suggesting building openblas from the source,

https://groups.google.com/d/msg/openblas-dev/pnQX-lHf6Wc/UfLG74ePDgAJ

would you, Radovan, agree with this solution ? No more openblas packages, but rather build OpenBLAS from the scratch - from the source.