Am Sun, 8 May 2016 11:33:07 +0300 schrieb Andrei Alexandrescu <[email protected]>:
> On 5/8/16 11:05 AM, Jonathan M Davis via Digitalmars-d wrote: > > On Sunday, May 08, 2016 02:44:48 Adam D. Ruppe via Digitalmars-d > > wrote: > >> On Saturday, 7 May 2016 at 20:50:53 UTC, Jonas Drewsen wrote: > >>> But std.net.curl supports not just HTTP but also FTP etc. so i > >>> guess that won't suffice. > >> > >> We can always implement ftp too, it isn't that complicated of a > >> protocol. > >> > >> Though, I suspect its users are a tiny minority and they might > >> not mind depending on a separate curl package. > > > > An alternative would be to move std.net.curl into a dub package. > > That would still be a breaking change, is that correct? > > I'm unclear on what the reasons are for removing libcurl so I'd love > to see them stated clearly. Walter's argumentation was vague - code > that we don't control etc. There have been past reports of issues > with libcurl on windows, have those not been permanently solved? > > I even see a plus: dealing with libcurl is a good exercise in eating > our dogfood regarding "interfacing with C libraries is trivial" > stance. Having to deal with it is a reflection of what other projects > have to do on an ongoing basis. > > > Andrei > The curl problems are more or less solved now, but it has caused quite some trouble: As long as we were statically linking curl: * We can't use curl when producing cross compilers for GDC as the minimal builds used by crosstool do not include curl. They do not even include zlib, we're just lucky that zlib is in GCC and we compile it statically into druntime. OTOH I'm not sure if we can get conflicts between our statically compiled zlib and libraries which link against zlib. * For static libraries, we don't need curl at link time, but for dynamic libraries we do need it. * There was the library versioning issue which made DMD builds unusable on some distributions. * http://bugzilla.gdcproject.org/show_bug.cgi?id=202 Even programs not using libcurl will sometimes require linking curl (This is because common templates such as std.conv.to might be instatiated in curl, so curl.o is pulled in, which depends on libcurl) * Library order when linking is important nowadays, so you need a way to specify -lcurl in the correct location relative to -lphobos Still open issues: * Even when dynamically loading curl, it introduces a new dependency: libdl for dynamic loading. This is not an issue for shared libraries, but the list of libraries which need to be hard coded when linking a static libphobos is already quite long: -lc -lrt -lm -ldl -lz -lstdc++ -luuid -lws2_32 In fact GDC doesn't link some of these yet and Iain doesn't want to add more special cases to our linking code (https://github.com/D-Programming-GDC/GDC/pull/182 https://github.com/D-Programming-GDC/GDC/pull/181). Additionally the complete API, integration with D features and performance is not really up to phobos standards. This is because of libcurl API limitations though, so there's nothing we can do about it. As long as we don't have a D replacement though, it's still the best HTTP client available...
