Hi Niels, ni...@lysator.liu.se (Niels Möller) skribis:
> l...@gnu.org (Ludovic Courtès) writes: > >> Reviving the discussion, as we’ve been discussing this at the GHM, and >> some people would really like to see it happen. :-) > > Great! Any summary of the discussion, for those of us who couldn't make > it there? Mostly a few people reaffirmed the need for this. > I'm attaching a patch from I tree I have around, without reading it > carefully. I'm not sure this is the latest version I worked with. Maybe > it's of some use. Yes, thanks. I just tried it, and here’s the status: - numbers.c uses ‘GMP_NUMB_BITS’, which is lacking; - it also still uses mpq’s, as Mark noted; - random.c uses ‘mpz_realloc2’, also lacking. >>> 1. The header file libguile.h. As far as I understand, this is a public >>> header file and it's use of <gmp.h> means that the public guile ABI >>> depends on gmp. >> >> The problem is that there’s a public API dealing with mpz_t: > > Exactly. To me, that seems like a potentially hairy problem to get > right. > >> SCM_API void scm_to_mpz (SCM x, mpz_t rop); >> SCM_API SCM scm_from_mpz (mpz_t rop); >> >> So, when mini-gmp is used, a <gmp.h> header should be installed as well, >> say under <libguile/mini-gmp.h>. WDYT? > > Maybe it would make sense with a level of indirection. User's could > include libguile/bignum.h, which would in turn include either mini-gmp.h > or the real gmp.h, depending on how guile was configured. Users are only supposed to include <libguile.h>; headers under libguile/ aren’t meant to be included directly. Currently including <libguile.h> pulls <gmp.h>. When mini-GMP is used instead, then <libguile/mini-gmp.h> would be pulled instead, transparently. > Users may also need some way of figuring out if they need to link with > -lgmp or not. libguile-2.0.la and guile-2.0.pc would provide that info. >>> Since mini-gmp is not binary compatible, >> >> I don’t think there’s a problem, because only mpz_t objects appear in >> the API, and they’re pointers. [...] > Hmm, or if you're saying that the use of mpz_t in guile's public API is > pointers only, that that might make things a little simpler. But things > will still break badly if the user's code is linked with gmp and guile > uses mini-gmp, or vice versa. Exactly, that’s the only case where it would break, AFAICS. And it’s probably an unlikely use case: users who want to use both GMP and Guile surely have libguile linked against GMP. >>> 4. mini-gmp has no mp_set_memory_functions. > > That's added now, with the subtle difference that mini-gmp doesn't pass > a valid size for the old_size argument for the free and realloc > functions. I don't think guile depends on that feature. No, it doesn’t. I’m slightly concerned about mini-gmp, though. It’s almost 5000 lines, mostly copied from GMP AIUI, but with no way to synchronize. How do you consider the maintenance cost of this? I understand some people want this, and I’m happy you’re helping, but the amount of work and duplication involved would definitely be a showstopper for me if you and Mark weren’t helping. Thanks, Ludo’.
