Openblas detection and test #173
Conversation
|
current problem is that libopenblas packages are not behaving well on testing virtual servers, have to find out more ... |
|
ah, I see no openblas package for osx, suggesting to skip this test for OSX |
miroi
force-pushed
the
openblas
branch
4 times, most recently
from
fcf1482 to
a5bbc59
Compare
|
Finally I got tests green ! Ready for merge. |
|
well, the 'bloody' part of this change was playing with travis-ci configurations, to see, which packages go well with the 'offending 'libopenblas package. |
|
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. |
|
what is "D.R.Y." ? ah, I found it , it means don't repeat yourself (DRY) |
- thanks to https://github.com/BVLC/caffe/blob/master/cmake/Modules/FindOpenBLAS.cmake - added dedicated openblas test, which has the same testing source the same as for the blas test (fc_openblas in test_openblas.py) - taken care of ENABLE_OPENBLAS variable - provide openblas package installation for .travis.yml in 2 extra platforms (thanks to Dominic Jodoin <[email protected]>) - closes dev-cafe#172 - .travis.yml : openblas and blas can be together, but not with lapack,atlas packages ! and atlas ! - test/test_openblas.py : test both blas and openblas in new test - test/test.py : test all excep openblas - reduced number of installed packages for blas+openblas to get travis-ci test passed - fc_blas unified with fc_openblas, no need to duplicate the code - WARNING: testing on travis-ci is shaky, sometimes is passes, sometimes not
|
I cannot integrate this as a PR. There is code repetition ( |
|
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 ? |
|
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. |
|
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. |
|
I have cleaned up your code on the |
|
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. |
|
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. |
|
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. |
|
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.... |
|
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. |
let us see if the CI test will pass...