On 08/01/16 19:29, Martin Uecker wrote:
Hi Ghisvail!- Binary packages split-up. I am not quite sure about the usefulness of the bart-dev package. The final compilation line shows:...i.e. the final output is one executable (bart) with private libraries (libbox, libgrecon...) linked statically. So it looks to me that these libraries are not intended to be used publicly?There are meant to be used and there are people who are using them for internal projects. Ofcourse, they currently use the source distribution of BART, but I think a -dev package would be useful in the long run. I also have a small image viewer build on top of the libraries, which I would like to package eventually: https://github.com/mrirecon/view
Good. Then, you might want to use libbart-dev as the package name, which is usually the naming convention for packages containing any libraries (in shared or static form).
- lapack-dev -> lapack-dev | lapack.so in your list of Build-Depends in d/control. That way your package can be built with optimized libraries like atlas or openblas.Sounds like a good idea, but I do not understand it. What does it mean to depend on "lapack.so"?
Using Build-Depends on liblapack-dev alone forces local source package build to have liblapack-dev installed.
Using Build-Depends on liblapack-dev | liblapack.so, a local source package build can be done with other BLAS providers than Netlib, such as libopenblas-dev or libatlas-dev.
Also one can replace liblapack.so using update-alternatives. Why would it matter what I compile against as all alternatives should be ABI compatible?
Absolutely. It is just that if I use OpenBLAS locally, I don't want to have to install lapack-dev to build bart, which would also mess up with my alternatives in the process. Using liblapack-dev | liblapack.so is just a bit friendlier.
FYI, the same trick is used for other dependencies with multiple backends such as OpenCL.
Hope this helped, Ghis