On Thu, 1 Jul 2004, Leopold Toetsch wrote:
No. Please not another library (like ICU), which we have to update in our tree as well. I'd like to just link against it, *if* the library is selected with Configure.
Agreed. This reminds me of the situation we faced in perl5 with database libraries. The core language had to support dbmopen(), but what database library to use? Berkeley DB was a high quality possibility, but it wasn't ported to a number of architectures where we wanted perl5 to run. It was (and still is) also being actively maintained and developed, so any version supplied with a perl source kit would likely end up forking from the standard distribution.
Many systems had other built-in ndbm or dbm libraries, and gdbm was another fairly widely-available alternative, but no individual library was as widely available as we hoped perl5 would be.
Our solution was to guarantee at least a minimal implementation by including the sdbm library, which we ported and maintained so it would compile everywhere that perl was built. The remaining options were supported as extensions.
I suspect a similar approach will be appropriate here.
GMP *is* already heavily optimized to take advantage of architecture features.
Yes, and, as such, probably needs considerable ongoing portability maintenance, and we don't want to wind up maintaining a forked version. (I note, for example, that I just tried gmp-4.1.3 on my Solaris 8/SPARC system, and it failed with assembler errors. I suspect results on at least some of the more unusual places we hope to run parrot will be similar.)
> - At first glange, GMP seems to handle its own memory allocation. It > would be much better if we did that ourselves.
The memory allocation is overridable at runtime.
In any case, that's a general problem not specific to GMP. Any interface to an external library is going to have to deal with that issue.
--
Andy Dougherty [EMAIL PROTECTED]
