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-set
For 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
