ni...@lysator.liu.se (Niels Möller) writes: A status update. It's almost usable by guile (may need to implement mp_set_memory_functions, and there are some patches needed to guile to avoid using mpq functions for conversions between fractions and doubles).
A nice milestone! As for GMP's own uses, I can compile gmp it with dumbmp.c cut down to the attached version, and then with copies of mini-gmp.[ch] in the top directory. Good. I suppose it doesn't matter much if some dumbmp.c functions remain, but I suggest that we at least rename the remainder to something more apt. After all, it isn't that dumb, that left stuff. Maybe it's getting time to move mini-gmp into the main gmp tree? As for the organization, it would be simplest to put the mini-gmp.[ch] files in the top directory, but then there's also the mini-gmp README file and the testsuite, which I'm not sure how they should be handled. It would be nicer to have it in a separate directory, both for GMP directory cleanness and for easy extraction by users. Maybe one should put everything in a subdirectory, and have gmp make check set up testing of it (passing any needed configuration as make variables on the make command line, since the mini-gmp testsuite is a plain Makefile with no autoconf). The mini-gmp testsuite still depends on GMP, which might be an undesirable circular dependency. Does such test dependency matter? Which are the dependencies? >From GMP's perspective, I don't think mini-gmp unit testing should be necessary. We didn't perform unit testing of dumbmp, but instead relied on testing of the generated data. (Assuming generated data testing is complete, testing mini-gmp as part of a GMP make check has a slight drawback; it might stumble on compiler bugs that are irrelevent to GMP, making "make check" cry wolf about the compiled GMP.) -- Torbjörn _______________________________________________ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
