Re: Packaging xsimd
On 2021-04-25 15:58, Julien Lamy wrote:
Le 25/04/2021 à 12:29, Nilesh Patra a écrit :
...
/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.
Certainly possible to get you porter access, the procedure is described
at https://dsa.debian.org/doc/guest-account/
Nilesh or I can sign your request.
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.
...
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?
Wait no, it doesn't work that way. Removing packages has to be
requested if it built in the past but no longer does so. I've had to do
that progressively with pygalmesh as it grows to exceed memory
limitations of non-intel systems.
But if it never built in the first place then there is no problem.
There's no package to remove. The build failures don't hold up the
package if they've been failing from the beginning.
For that reason, better to have failing build logs, I think. Once xsimd
fixes its handling of other arches, it won't have to renege on that.
I've asked upstream for more info about which architectures they
support (https://github.com/xtensor-stack/xsimd/issues/460).
Thanks. It'll be helpful to hear what upstream says.
Apart from libsimde-dev, there's also libssw0 which is passing tests on
all arches
(there's libpsimd-dev too, but it's not running any tests)
So in principle a SIMD package can work with all arches.
...
>> * 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:
...
The difference is that xsimd is not a library, it's a header
package.
There is no libxsimd.so.
...
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.
I think your arguments are stronger than mine on this point. Better to
change xtensor.
It was only reintroduced last month, so now is a good time to change it.
I'll get that in train.
Drew
Reply to: