Jonathan M Davis:

> At minimum, I think that we should avoid putting any
> more 3rd party dependencies in Phobos in the future.

I am not expert/qualified enough to discuss about all this, but having some "batteries included" in D is nice. I am using curl in D. I'd even like in the standard D distribution some mean to produce a little graphics on the screen, shared on all systems D compiles on (like the simplegraphics.d module).

Bye,
bearophile

On 11/25/13 5:51 PM, Martin Krejcirik wrote:
> On 25.11.2013 8:38, Jordi Sayol wrote:
>> As Jonathan M Davis said: --- Several of the main devs (including
>> Walter) have stated that having std.net.curl on Phobos was a mistake
>> given all of the problems that we've had with it on Windows and Linux
>
> I'm for removing as I always compile Phobos without curl anyway (I don't
> want to install all dependencies).

Does curl in turn depend on many other libraries?

Andrei

El 26/11/13 01:36, Jonathan M Davis ha escrit:
[...]
> 
> At this point, I'm inclined to argue that Phobos should not depend on any libraries other than the system libraries for each OS so that we can avoid further dependencies that may not be available - especially when it comes to Windows, since Windows comes with no 3rd party development libraries at all. So, I would very much be against std.net.curl's inclusion at this point and would argue that it should be in a library separate from Phobos and that if we want similar functionality in Phobos, we need to implement it without relying on anything other than system libraries. And from previous discussions on the topic, I believe that Walter and several other dmd/Phobos devs agree with that.
> 
> So, I'm all for removing std.net.curl, but if we do that, we'd obviously need to deprecate it first rather than simply removing it, and we'd need to have a separate library with std.net.curl in it (preferably one which could be pulled in via dub) which people could switch to using instead. Whether that library would be maintained by us, by Jonas (since he created it), or someone else, I don't know, but ideally, it wouldn't be in Phobos any longer. At minimum, I think that we should avoid putting any more 3rd party dependencies in Phobos in the future.
> 
> - Jonathan M Davis
> 

+1

-- 
Jordi Sayol

On Tuesday, 26 November 2013 at 00:13:57 UTC, Andrei Alexandrescu wrote:
> (far as I understand, the likes of php and python are doing fine with curl, but maybe I'm wrong).

If you have a look at Python download page (http://www.python.org/download/) they don't provide binaries for Linux, only source tarball. And Windows installer includes curl AFAIK.

El 26/11/13 03:11, Andrei Alexandrescu ha escrit:
> On 11/25/13 5:51 PM, Martin Krejcirik wrote:
>> On 25.11.2013 8:38, Jordi Sayol wrote:
>>> As Jonathan M Davis said: --- Several of the main devs (including Walter) have stated that having std.net.curl on Phobos was a mistake given all of the problems that we've had with it on Windows and Linux
>>
>> I'm for removing as I always compile Phobos without curl anyway (I don't want to install all dependencies).
> 
> Does curl in turn depend on many other libraries?
> 

On Debian testing (64-bit):

$ ldd /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0
	linux-vdso.so.1 (0x00007fff36519000)
	libidn.so.11 => /usr/lib/x86_64-linux-gnu/libidn.so.11 (0x00007f28ccdc5000)
	librtmp.so.0 => /usr/lib/x86_64-linux-gnu/librtmp.so.0 (0x00007f28ccbab000)
	libssh2.so.1 => /usr/lib/x86_64-linux-gnu/libssh2.so.1 (0x00007f28cc982000)
	libssl.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f28cc724000)
	libcrypto.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f28cc332000)
	libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007f28cc0f2000)
	liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x00007f28cbee3000)
	libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x00007f28cbc92000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f28cba79000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f28cb85d000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f28cb4b1000)
	libgnutls.so.26 => /usr/lib/x86_64-linux-gnu/libgnutls.so.26 (0x00007f28cb1f1000)
	libgcrypt.so.11 => /lib/x86_64-linux-gnu/libgcrypt.so.11 (0x00007f28caf72000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f28cad6e000)
	libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007f28caa99000)
	libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007f28ca870000)
	libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007f28ca66c000)
	libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007f28ca462000)
	libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007f28ca25e000)
	libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f28ca047000)
	libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007f28c9e2b000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f28cd28e000)
	libtasn1.so.3 => /usr/lib/x86_64-linux-gnu/libtasn1.so.3 (0x00007f28c9c1a000)
	libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007f28c99fa000)
	libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f28c97f6000)

-- 
Jordi Sayol

I don't use curl (at this point), I use D on Debian and Windows. I have had no issues with curl dependencies.

Reading the issues at hand it looks they all come from people actually trying to use curl. It sounds like this suggest isn't a solution but a means to clean ones hands of the problem.

I don't think I understand having to build dmd just because you have a different distribution, Phobos maybe but dmd... Even for Phobos I'm skeptical but am not going to install a different distro to experiment myself.

If it is moved to a third party library, the problems will still remain. If the Phobos team is expected to support it, then the burden hasn't shifted either.

On Tue, Nov 26, 2013 at 06:44:03AM +0100, Jesse Phillips wrote: [...]
> I don't think I understand having to build dmd just because you have a different distribution, Phobos maybe but dmd... Even for Phobos I'm skeptical but am not going to install a different distro to experiment myself.

If you have used enough Linux distros (or even different versions of the same distro!), you will realize that all it takes is for a single shared library on the system to be a different version, missing, or just the same version built with different compiler flags, and the executable will not work. Not to mention that filesystem layout can be different across distros (and versions of the same distro), which will break things.

Basically, to guarantee a program runs on distro X, the only way is it has to be built from source. If you're lucky, somebody else has already done that, and you can just download the binary. (Or better yet, somebody packaged it for your distro, then you can just install it via your system's package system.) But if not, you'll just have to do it yourself.

Copying an executable from one Linux box to another is generally a bad idea. If it runs at all, there's a chance that it is actually subtly malfunctioning. I've seen heisenbugs that have no representation in source code, but show up when you run an executable in an environment that's close to, but not quite, the environment it was built on. Rebuilding from source (often with exactly the same commands, same compile flags, etc.) makes the problems go away.


> If it is moved to a third party library, the problems will still remain. If the Phobos team is expected to support it, then the burden hasn't shifted either.

This I agree with. However, it misses the point. The point is that the core D toolchain (dmd/phobos/druntime) would have one less dependency, which is generally a good thing, because you want to make it as easy as possible for people to get a working compiler up and running.  Requiring this library and that library and that other tool, just to get a bare bones D toolchain working, is a good way to turn people off D. If a bare bones D compiler is actually working, then they'd have more incentive to actually put in more effort to make the frills work too. Having a hello world program be uncompilable just because libcurl isn't available, is a very bad first impression ("why does this stupid language need libcurl just to compile a hello world program?!").


T

-- 
EMACS = Extremely Massive And Cumbersome System

On Tuesday, 26 November 2013 at 00:36:22 UTC, Adam D. Ruppe wrote:
> On Windows, the problem is simply that curl isn't packaged with dmd

I see the required DLLs for win32 are in dmd2\windows\bin (libcurl.dll, libeay32.dll, libssl32.dll) and in dmd2\Windows the needed stuff for SSL (certificate bundle). At least, the docs should be improved so that the user knows he has to deliver these files with his EXE and has to enable the certificate bundle.

On 2013-11-26 07:53, H. S. Teoh wrote:
> Having a hello world program be uncompilable just because libcurl isn't available, is a
> very bad first impression ("why does this stupid language need libcurl
> just to compile a hello world program?!").

Isn't curl only needed if std.net.curl is actually used? I have never used std.net.curl and I never had any problems with it tough. Although I use Mac OS X where curl is pre-installed.

-- 
/Jacob Carlborg

On Tuesday, 26 November 2013 at 02:22:50 UTC, Jordi Sayol wrote:
>
> On Debian testing (64-bit):
>
> $ ldd /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0
> 	linux-vdso.so.1 (0x00007fff36519000)
/snip

Evidently, Debian builds curl with --enable-everything-under-the-sun.  Here's mine, with just ssl (via OpenSSL) support:

wyatt@Yue ~ $ ldd /usr/lib/libcurl.so
        linux-vdso.so.1 (0x00007fff7f7ff000)
        libssl.so.1.0.0 => /usr/lib64/libssl.so.1.0.0 (0x00007ff835865000)
        libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 (0x00007ff83547c000)
        libz.so.1 => /lib64/libz.so.1 (0x00007ff835265000)
        librt.so.1 => /lib64/librt.so.1 (0x00007ff83505c000)
        libc.so.6 => /lib64/libc.so.6 (0x00007ff834cb2000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007ff834aad000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007ff834890000)
        /lib64/ld-linux-x86-64.so.2 (0x00007ff835d73000)

I'll be generous and allow that zlib might somehow be a sticking point, but there's really nothing unexpected here, IMO.

-Wyatt