Code organisation of mini-gmp

[Niels Möller]

Torbjorn Granlund <tg at gmplib.org> writes:

> I think we should consider splitting it up into many files, basically
> one-function-per-file.  The mini-gmp.c file would #include them all.

I agree this makes some sense. A few minor drawbacks: One may have to
make a few currently static functions non-static. And we may need a
mini-gmp-internal.h for internal macros.

> If we really want to keep mini-gmp as one file (why?) then we should at
> least play tricks with conditional inclusion for each and every
> function,

If it's possible to divide the features into pieces based on at most,
say, ten #defines available for users, then I think it would make sense
to keep at as a single file and manage dependencies manually at
preprocessor time.

But if it get's more complex than that, then I think it's preferably to
use a file per function and let the linker sort out the dependencies.
What tools are available for extracting the dependency graph for the
current functions in mini-gmp?

One difference in organization, compared to gmp, is that division
functions are organized as a general (but static) mpz_div_qr. Then the
various mpz_?div_* functions (and a couple of others) are single line
wrappers calling this function with different arguments. I don't think
there's much benefit in putting all of these wrapper functions in
separate files.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.