Walter Bright:
as soon as the D *package* starts to depend on
non-default-installed libraries, trouble happens. With libcurl,
the only solution so far seems to be to BUILD OUR OWN LIBCURL
binary!
http://d.puremagic.com/issues/show_bug.cgi?id=10710
This is a terrible situation.
For Haskell they release two different kinds of
compilers+libraries: one is just a core distribution with the
compiler with the standard Haskell modules (including the GMP
compiled binaries), and the other contains the compiler with its
standard library, plus modules+binaries for the most common
libraries.
Python on Windows uses a similar strategy.
Consider things like the trig functions. D started out by
forwarding to the C versions. Unfortunately, the C versions are
of spotty, unreliable quality (even today!). Because of that,
we've been switching to our own implementations.
And, consider that using GMP means CTFE would not be supported.
At the moment BigInt doesn't run at compile-time.
You could wrap an external fast multi-precision library in Phobos
D code that uses __ctfw to switch to a simpler pure D
implementation at compile-time.
Is it useful to use BigInts at compile-time? If the answer is
very positive then perhaps the D interpreter could be modified to
allow calling external numerical libraries even at compile-time.
Note that D was developed with existing backends and linkers.
But isn't optlink being rewritten in C? Perhaps I am just
confused, sorry.
Bye,
bearophile
