On 11/25/13 10:53 PM, H. S. Teoh wrote:
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.

Do we with our std.net.curl make this matter any worse?

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.

But my understanding is that the dependency is conditional, i.e. you have no dependency on libcurl unless you attempt to use std.net.curl. Which strikes me as entirely reasonable. No?

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.

Bare bones == no std.net.curl. No?

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?!").

My understanding is that a missing or broken libcurl does not break hello world. Is that correct?

As a note regarding my many messages in this thread: I decided to get to the bottom of this given that I've asked "what is exactly the problem with libcurl" and all I got was unclear answers.


Thanks,

Andrei

Reply via email to