On Fri, 2015-08-07 at 11:24 +0100, Ghislain Vaillant wrote: > > It is not a requirement though. Just have a quick thinking whether this > meta-package is really needed or not. I think it's not necessary. Maybe it's ok just let the user choose one between "caffe-cpu" and "caffe-cuda". > What are these packages supposed to contain ? Executables ? GUI apps ? e.g. caffe-cpu : some elf executables linked to libcaffe.so.0 libcaffe-cpu0 : libcaffe.so.0 libcaffe-cpu-dev : corresponding dev files > I am not sure I am following you here. In another word I mean, "caffe-cuda" is only provided for arch:i386 and arch:amd64, while "caffe-cpu" is for arch:any. > Feel free to checkout ArrayFire, clBLAS, clFFT, for examples of > CMake-using d/rules. > > From the official instructions for caffe, it seems that you may require > an override for the tests, to run "make runtests" instead of the > standard "make tests". Otherwise, their CMake seems pretty standard and > all you need to figure out is the right CMake build options to pass to > dh_auto_configure. Thank you for pointing some examples for me. I was surprised when switching default build system from Make to CMake, because -D<var>=<val> option of cmake does good job at configuring. Now I have successfully bumped the default build system to cmake. Result of my local build of caffe-cpu seems good. Meanwhile, the d/rules should be more clear to read. Next I'm going to find a solution fixing nvcc compiling error of caffe-cuda[1]. [1] https://github.com/BVLC/caffe/issues/2638 -- .''`. Lumin : :' : `. `' `- 638B C75E C1E5 C589 067E 35DE 6264 5EB3 5F68 6A8A
Attachment:
signature.asc
Description: This is a digitally signed message part