[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Packaging xsimd

Le 25/04/2021 à 12:29, Nilesh Patra a écrit :

Hi Drew and Julien,
On Sun, 25 Apr 2021 at 15:41, Drew Parsons <dparsons@debian.org <mailto:dparsons@debian.org>> 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.
Reply to: