Should "std.net.curl" be moved from Phobos to Deimos?

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Tue Nov 26 11:06:26 PST 2013


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



More information about the Digitalmars-d mailing list