Niels, My thinking is that we don't know what it might need to be extended to in the future. By modularizing everything, it could conceivably be created so that there's a ./configure option which allows the creation of an extract of the source code for the target, which would create a portion of the full GMP source that can be stand-alone compiled in a particular way, such as meets the specific / variable needs of the target user's app.
However, should those needs change at some point in the future, rather than coming back to GMP and saying "Hey, this mini-gmp is great. I need X added to it for my app. Could you please add that?" Or, by asking (expecting/forcing) the user to do it for themselves by contributing back to the project ... why not go ahead from the beginning and isolate individual components that then can be included by their logical breakout? The person wanting to bundle a specfic portion of GMP with their project in native source code could use the ./configure output which generates an output directory with all of the source files necessary to compile only that portion (portions) they're after. And if it changes in the future, by adding another --enable-x or --enable-y option will now include those source files as well. I realize this is a larger task than creating mini-gmp, though probably over time with the singular maintenance of only GMP then (and not two packages) it may be equal or even less, it will address a far wider range of variables needed by target users, of whom we don't know the full extent of their needs today, but can easily recognize they will, at least, be varied. I do see value in creating a 10x slower version using far simpler (smaller, easier-to-understand) algorithms so that end-users can extend that code base for their own needs. Such would be valuable for non-critical non-high-speed apps. However, I would also make that an option through the configuration settings, to allow either the proper (full) GMP algorithms to be used, or the simpler ones, both to build the GMP binaries and libraries, as well as to generate the output source code for the targeted/embedded solutions some users need. Hope this makes sense. :-) - Rick C. Hodgin --- On Wed, 12/28/11, Niels Möller <ni...@lysator.liu.se> wrote: > From: Niels Möller <ni...@lysator.liu.se> > Subject: Re: mini-gmp > To: "Rick Hodgin" <foxmuldrs...@yahoo.com> > Cc: gmp-devel@gmplib.org > Date: Wednesday, December 28, 2011, 1:29 PM > Rick Hodgin <foxmuldrs...@yahoo.com> > writes: > > > I suggest making components of the native full-blown > GMP modular. > > That would be nice, but I don't think it solves the same > problem. The > point of mini-gmp is that it can be easily bundled (as part > of the > source tarball) with other projects, with little added > complexity. If > you bundle the full gmp library (some do, e.g., the Pike > interpreter), I > imagine it usually would make little sense to actually > build a stripped > down version of it; if you already have the full sources > and the complex > complex configure machinery, why not simply build the > complete library? > > Regards, > /Niels > > -- > Niels Möller. PGP-encrypted email is preferred. Keyid > C0B98E26. > Internet email is subject to wholesale government > surveillance. > _______________________________________________ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
