Hi Paul,
So what do we do?
Might we enter into discussion with GMP and mfpr developers to get explicit permission to package their library within Boost?
CGAL already distributes the Windows versions of gmp and mpfr, so I know they don't mind. OTOH, there are practical issues with distibuting them since they cannot be built in windows without the separate port provided by Brian Gladman: http://www.gladman.me.uk/
IANAL but I feel this issue should be resolved and a decision recorded.
At the very least I think it should be discussed whether is OK or not to depend on external components, to what extent, and how so. As pointed out by Sebastian Redl, there is some form of precedence to this in Boost.Python and Boost.MPI, both naturally requiring Python and MPI, resp. Those libs are specifically wrappers for the external components, while in the case under consideration (GTL), the external GMP (and potentially MPFR) libs are DEPENDENCIES, thus it could be argued that this is different than Boost.Python and Boost.MPI and the required functionality *should^* exist within Boost itself. A much more direct precedence for the GTL case is the Boost.Rational library. It depends on an integer concept and external big integers are reasonable and even almost required in practice. But the GTL case is slightly different because, IMO, the dependent concept should explicitely require unlimited precision since the library specifically uses it to *guarantee* robustness. Thus, unlike the case with Boost.Rational, users should be totally forbiden from using built-in types. They should be left with no choice but to pick some external component fulfilling the unlimited precision requirement, otherwise, GTL will have no choice but to fail to guarantee 100% robustness. From the POV of standarization of boost libraries (one of the principal goals), dependencies on libraries such as GMP or MPFR poses a problem since those libraries provide highly mature *C* interfaces, not C++ (there is a gmpxx wrapper lib but it is hardly used compared to the gmp C API). They can't and won't ever be standarized, at least not within the "C++" SCL (but they could theoretically be standarized in std C and so included in std C++) OTOH, producing a high quality Boost library equivalent in performance and functionality to GMP/MPFR is very very difficult since those GNU projects have been evolving and maturing for many years. It seems to me somewhat unrealistic to expect something like that in Boost. A different and much less ambitious goal could be to come up with a good C++ *interface* to *those* libraries. That is, C++ number types specifically designed to be implementable on top of a C API like that of GMP and MPFR. As to what to require to GTL, I think it should be allowed to depend on concepts which have no models on either native types nor standard library or boost components, even if that clearly indicates the need for an external library. Best -- Fernando Cacciola SciSoft Consulting, Founder http://www.scisoft-consulting.com