Hi Kari,
Thanks for your review. I appreciate your guidance.
A suggestion: The documentation package could include an examples subdirectory in /usr/share/doc/librocalution-doc and it could install the cpp files from the clients directory to it. And the package could provide a Makefile to compile them as well, since using cmake for that purpose would be overkill. /usr/share/doc/libgecode-doc/examples if you want to check how I did it for Gecode.
I've added the stand-alone examples to the doc package. The build process for each example is just linking against rocalution. e.g. `g++ /usr/share/doc/librocalution-dev/examples/amg.cpp -lrocalution`. Would this be sufficient to proceed with the initial upload? We can further refine the provided examples in later updates.
I did not add a Makefile to the package, but I've attached one to consider. Is the expectation that users will copy the examples directory to their home folder before calling `make`?
Also, it wasn't obvious to me what an mtx file was that the samples required, I found an example from https://github.com/NVIDIA/AMGX/blob/main/examples/matrix.mtx. It wouldn't hurt to include an example of that as well.
It would be nice to have a representative example. Ideally, we would package some of the matrices from the eponymous Matrix Market [1] or the SuiteSparse Matrix Collection [2] in their own data packages. However, it's not clear to me whether Debian can redistribute any of those files.
I see that you've added the Debian revision to the shlibs file. This should only be used if the ABI changes between Debian revisions. Quoting the policy: Dependency versions in either symbols or shlibs files normally should not contain the Debian revision of the package, since the library behavior is normally fixed for a particular upstream version and any Debian packaging of that upstream version will have the same behavior. In the rare case that the library behavior was changed in a particular Debian revision, appending ~ to the end of the version that includes the Debian revision is recommended, since this allows backports of the shared library package using the normal backport versioning convention to satisfy the dependency.
Opps. I was looking for more references on how to use shlibs and I was mislead by a secondary source [3]. I've made the correction. Thanks for catching that mistake!
I've uploaded a new version to mentors / salsa incorporating your feedback. I also noticed that I'd missed adding a clean target, so it corrects that as well.
Sincerely,
Cory Bloor
[1]: https://math.nist.gov/MatrixMarket/
[2]: http://sparse.tamu.edu/
[3]:
https://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#shlibsfile
LDLIBS ?= -lrocalution
examples = amg \
as-precond \
async \
benchmark \
bicgstab \
block-precond \
cg-amg \
cg-rsamg \
cg-saamg \
cg \
cmk \
complex \
direct \
fcg \
fgmres \
fixed-point \
gmres \
idr \
key \
me-preconditioner \
mixed-precision \
power-method \
sa-amg \
simple-spmv \
sp-precond \
stencil \
tns \
ua-amg \
var-precond
.PHONY: all
all: $(examples)
.PHONY: clean
clean:
$(RM) $(examples)