On 26.11.2013 20:02, Andrei Alexandrescu wrote:
>> (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)
>>
> 
> But those are already installed libraries, right?

The problem (in my case) is, that you also need to install the -dev
packages of these libraries just to compile Phobos (even if you don't
use curl in your programs at all).

Maybe we just need something like --without-curl for Phobos makefile.

-- 
mk

On Tuesday, 26 November 2013 at 21:04:31 UTC, Andrei Alexandrescu wrote:
>> I really think providing just source + single additional .deb package as
>> an example is the best way to go.
>
> Well we kind of do that already. No?
>
> Andrei

No. We provide Linux binaries in .zip and pretend they are expected to work for all distros which simply can't happen in general. Fedora bug report would not have been valid if not implication that there is a supported binary distribution for Fedora.

I suggest to simply stop pretending any kind of such support exist and drop Linux binaries from .zip at all. Motivating people to create dmd packages for their native distros scales much better (and solves most/all curl issues for Linux)

On 2013-11-27 11:26, Martin Krejcirik wrote:

> The problem (in my case) is, that you also need to install the -dev
> packages of these libraries just to compile Phobos (even if you don't
> use curl in your programs at all).
>
> Maybe we just need something like --without-curl for Phobos makefile.

That's only needed when compiling as a shared library.

-- 
/Jacob Carlborg

On Wednesday, 27 November 2013 at 10:26:50 UTC, Martin Krejcirik wrote:
>
> The problem (in my case) is, that you also need to install the -dev
> packages of these libraries just to compile Phobos (even if you don't
> use curl in your programs at all).
>
As usual, -dev packages just make life worse for people and offer no real benefit. :/

> Maybe we just need something like --without-curl for Phobos makefile.

If it's _really_ important that a curl binary is distributed with D, it should be built statically.  But I doubt it's actually THAT important.

Make it a proper dep and let the distro packagers do what they do best.  The --without-curl switch is a good idea, btw.

-Wyatt

On Wednesday, 27 November 2013 at 07:39:17 UTC, Jacob Carlborg wrote:
> Doesn't GnuTLS provide an OpenSSL API?

idk. If so, that's easy. I've just seen curl compiled separately for gnutls and openssl so I assumed they must be different.

Nevertheless, I really think dynamic linking is the way to go here since that can gracefully degrade when no ssl library is available at all too.

On Wednesday, 27 November 2013 at 14:07:02 UTC, Wyatt wrote:
> Make it a proper dep and let the distro packagers do what they do best.  The --without-curl switch is a good idea, btw.

Distro packagers don't have any issues even now (assuming they build stuff locally). It is all about "official" .zip

On Wednesday, 27 November 2013 at 08:45:37 UTC, Andrea Fontana wrote:
> Should we consider interoperability with std.path too?

Generally, I think no, though it would be easy enough to get uri.path as a decoded string and pass it to those functions.

But std.path is a bit different on Windows and Linux (I think; I've never actually used it), whereas urls have a slightly different and stricter interpretation (which may be treated like win or lin depending on the server).

> I worked on http protocol, and I don't think that's will be a big issue. Http client side is not so complex if you need a working subset. I think we don't need gzip compression in first release, for example.

Yeah, http is pretty simple. Even gzip isn't really hard.

> +1 for an oauth module. It would be very useful to work with third party api (facebook, google, etc ...) and to write api too! However I think it depends on http(s) module.

Yup. I wasn't thinking of putting the server code in the std.net.http, though I have some in my oauth.d (isSignatureValid, isOauthRequest, etc., the functions that take a Cgi parameter) I've barely actually used it, so it is probably buggy, but it is there and wasn't horribly hard to write after getting the client working.

(The biggest pain with clients btw? Buggy servers! It has gotten a little better, but when I started with this, Twitter, LinkedIn, and AWeber, the three I had to use.... all interpreted the spec slightly differently, so what worked on one wouldn't work on the other two, and, of course, the error messages are  never helpful and the documentation sucks. Massive pain.)

On 11/27/13 2:26 AM, Martin Krejcirik wrote:
> On 26.11.2013 20:02, Andrei Alexandrescu wrote:
>>> (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)
>>>
>>
>> But those are already installed libraries, right?
>
> The problem (in my case) is, that you also need to install the -dev
> packages of these libraries just to compile Phobos (even if you don't
> use curl in your programs at all).
>
> Maybe we just need something like --without-curl for Phobos makefile.

We could add that. I'll note that building Phobos is something for the experts only.

Andrei

On 11/27/13 4:56 AM, Dicebot wrote:
> On Tuesday, 26 November 2013 at 21:04:31 UTC, Andrei Alexandrescu wrote:
>>> I really think providing just source + single additional .deb package as
>>> an example is the best way to go.
>>
>> Well we kind of do that already. No?
>>
>> Andrei
>
> No. We provide Linux binaries in .zip and pretend they are expected to
> work for all distros which simply can't happen in general. Fedora bug
> report would not have been valid if not implication that there is a
> supported binary distribution for Fedora.
>
> I suggest to simply stop pretending any kind of such support exist and
> drop Linux binaries from .zip at all. Motivating people to create dmd
> packages for their native distros scales much better (and solves
> most/all curl issues for Linux)

I agree the business with distributing all binaries for all platforms in the .zip is just weird. We should drop it for the New Year's release.

Andrei

On Wed, Nov 27, 2013 at 10:00:38AM -0800, Andrei Alexandrescu wrote:
> On 11/27/13 4:56 AM, Dicebot wrote:
[...]
> >No. We provide Linux binaries in .zip and pretend they are expected to work for all distros which simply can't happen in general. Fedora bug report would not have been valid if not implication that there is a supported binary distribution for Fedora.
> >
> >I suggest to simply stop pretending any kind of such support exist and drop Linux binaries from .zip at all. Motivating people to create dmd packages for their native distros scales much better (and solves most/all curl issues for Linux)
> 
> I agree the business with distributing all binaries for all platforms in the .zip is just weird. We should drop it for the New Year's release.
[...]

Didn't Nick already write a script that would generate separate tarballs / zipballs / whatnot for each supported platform?

I agree that putting *all* platforms in a *single* zip is very strange. It makes people wonder, "why did they make me download the binaries for every single platform out there when I only need support for one platform?"


T

-- 
Doubt is a self-fulfilling prophecy.