Le 25/04/2021 à 12:29, Nilesh Patra a écrit :
Hi Drew and Julien,
On Sun, 25 Apr 2021 at 15:41, Drew Parsons <[email protected]
<mailto:[email protected]>> wrote:
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)
| ^~~~~~~~~~
Similar error as with the ppc64el porter box: these seem to be more
related to googletest (the unit test framework used by xsimd) than to
xsimd itself.
@Nilesh: as a non-DD, non-DM, can I apply to get access to a porter box
(armhf is more likely to be supported than ppc/mips)? If not, I'll
investigate using Qemu.
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#ppc-architecture>
https://xsimd.readthedocs.io/en/latest/api/instr_macros.html#generic-instruction-set
<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/
<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?
I've asked upstream for more info about which architectures they support
(https://github.com/xtensor-stack/xsimd/issues/460).
...
>> * 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>
>
>>
<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.
Eigen3 (https://tracker.debian.org/pkg/eigen3) also has the "lib" prefix
on the packages, while some C++ unit test libraries (e.g. catch,
https://tracker.debian.org/pkg/catch) don't. I don't have a strong
opinion one way or the other: both of you have more packaging experience
than I do, I'll let you decide which one to keep.
