On 2021-04-25 09:56, Julien Lamy wrote:
Le 22/04/2021 à 19:30, Nilesh Patra a écrit :
...
I tried in a ppc64el porter box, and I get several of:/home/nilesh/xsimd/xsimd/test/test_batch_bool.cpp:315:1: error: 'gtest_type_params_batch_bool_test_' was not declared in this scope; did you mean 'gtest_type_params_batch_bool_test_NameGenerator'?315 | TYPED_TEST(batch_bool_test, load_store)
...
And a failing build. Both for build time as well as autopkgtests.Do you think we should for now limit arches to amd64 i386 and arm64 in d/control for now?Since upstream only supports x86 and ARM (v7 + v8) instruction sets and since I don't have access to either mips or ppc boxes, I think restricting to the corresponding arches makes sense. I've added armhf to the ones you mention, as it should be in the supported list (I'm not familiar with ARM, let me know if it was a mistake).
We don't really gain much by limiting the arches in a new package, but what we would lose are the build logs documenting the issue. The package build will look "clean", but we would lose the documentation of the problem on the other arches.
Note that the xsimd documentation does refer to both PPC and "generic" support,
https://xsimd.readthedocs.io/en/latest/api/instr_macros.html#ppc-architecture https://xsimd.readthedocs.io/en/latest/api/instr_macros.html#generic-instruction-setFor comparison, libsimde-dev passes tests on all arches, https://ci.debian.net/packages/s/simde/
We can't inspect the problems in the build logs as readily if they are never created.
...
* Why is the package named xsimd-dev instead of libxsimd-dev? It might match xtensor, but AFAICS that's against the library style packaging. For ref: https://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html<https://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html>It was indeed chosen to match xtensor/xtl. I've reverted it to match the usual naming (libxsimd-dev / libxsimd-doc).
The difference is that xsimd is not a library, it's a header package. There is no libxsimd.so.
So the naming rules are not so clear cut for header packages. But simde does use libsimde-dev.
In the case of xsimd, it's part of the xtensor family, so for that reason I would recommend following xtensor's convention. Perhaps xtensor should be changed to libxtensor-dev, but the reason (or history) for it being different is that it's header-only.
Drew