request: libgmp

[bentitmus]

https://gmplib.org

We have a wrap file and meson.build patch for a project that uses GMP in a cross compile on GitLab. It would be preferable if this were in wrapdb (and if it was reviewed by someone who knows what they are doing!). Most of the way it is implemented could be done better.

[jpakkane]

Repository created, please file a MR.

https://github.com/mesonbuild/libgmp

Thanks.

[Stepland]

Bumping this because I'd like to help.

Would there be any real worth-the-effort benefit to writing a wrap for gmp that does not rely on unstable_external_project ?

I'm asking this because I've had a quick look at the current build system for gmp and it's just one obnoxiously large autotools script I'm having a hard time understanding

[eli-schwartz]

Yes, running the autotools script via the external project module may not be possible on Windows without installing a bunch of software (mingw userland providing a shell, coreutils, make, etc.) whereas configuring it natively via meson.build won't require any additional dependencies.

That being said, using the external project module is the path of least resistance and almost certainly unblocks your personal work at least on Unix, so that might suffice.

[oscarbenjamin]

GMP's configure script is overly complicated for most purposes where only basic functionality of GMP is needed and maximum possible speed might be unimportant. Most of what it is doing is just enumerating every possible CPU architecture. As noted in configure.ac:

# This code has various related purposes
#
#   - better default CC/CFLAGS selections than autoconf otherwise gives
#   - default CC/CFLAGS selections for extra CPU types specific to GMP
#   - a few tests for known bad compilers
#   - choice of ABIs on suitable systems
#   - selection of corresponding mpn search path

The last point is the main one which is that it chooses which assembly routines to use:
https://gmplib.org/repo/gmp/file/tip/mpn

The meson patch file linked above passes --disable-assembly and so basically shortcuts all of that complexity by falling back to generic C routines. That is probably acceptable for many purposes.

For my purpose I want --enable-fat which bundles routines for all CPU architectures and selects them at runtime. It don't think it is possible to compile like that with MSVC or generally read any of the assembly code with MSVC.

Probably the vcpkg configuration is a better starting point for figuring out how to write a meson configuration rather than looking at GMP's configure.ac:
https://github.com/microsoft/vcpkg/blob/5fa0f075ea51f305b627ecd5e050a363707353ff/ports/gmp/portfile.cmake#L26-L93