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).
@Julien that does not work on armhf, I built on a porter box to check as well
several of these:
/home/nilesh/xsimd/xsimd/test/test_api.cpp:222:1: error: ‘gtest_type_params_xsimd_api_test_’ was not declared in this scope; did you mean ‘gtest_type_params_xsimd_api_test_NameGenerator’?
222 | TYPED_TEST(xsimd_api_test, store)
| ^~~~~~~~~~
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.
I agree with you there, we would have the logs. _However_ if going forward, upstream says that
it cannot build on all arches that Debian supports, we would have to file a removal bug for those arches.
And then wait for the FTP team to process that removal, and it's a bit of a mess.
Rather maybe we could upload first with limiting arches - and since the error on ppc64el looks similar to armhf,
we could ask upstream to extend support for these, and change arch to any in subsequent uploads?
What do you think?
...
>> * 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.
Right.
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.
It'd be nice if everything could be prefixed with a "lib". It creates less confusion and gives a clear idea
that the package would indeed contain header files. There's also "paryfor"[1] as another example than simde which is header-only package.
Nilesh