On Wed, 04 Sep 2013 13:22:39 +0200
Jacob Carlborg <doob@me.com> wrote:

> On 2013-09-04 13:16, Nick Sabalausky wrote:
> 
> > Actually, that's a good point, I have to double-check that. I don't remember adding any code to skip 64-bit on FreeBSD, *but* I was careful to make everything match the v2.063.2 release zip as closely as possible, so I might have omitted it under the assumption that "Well, this release zip doesn't have bin64 or lib64 for bsd, so I guess it's not considered ready for prime-time yet."
> 
> The latest release of DMD for FreeBSD only includes 32bit binaries.
> 

Yea, that's why it's possible I might have excluded 64-bit for FreeBSD (and then forgot I did so). I'll check.

On 2013-09-04 13:24, Nick Sabalausky wrote:

> That's the "use X number of simultaneous processes" flag, right? Good
> idea, I'll add a -j flag and pass it through to make.

Yes.

-- 
/Jacob Carlborg

On 04/09/13 13:21, Jacob Carlborg wrote:
> On 2013-09-04 13:01, Nick Sabalausky wrote:
> 
>>> Requires Debian 7.0 or later. For Debian 6, install the the packages "gcc-multilib" and "ia32-libs".
>>>
>>
>> I definitely have multilib on there since other stuff works 32-bit (like rdmd). It's just libcurl that I can't seem to get 32-bit or multilib.
> 
> I would be very surprised if libcurl isn't included in ia32-libs.
> 

Yes, "ia32-libs" depends on "ia32-libs-i386:i386" which depends on "libcurl3:i386"

-- 
Jordi Sayol

On Wed, 04 Sep 2013 13:54:35 +0200
Jordi Sayol <g.sayol@yahoo.es> wrote:

> On 04/09/13 13:21, Jacob Carlborg wrote:
> > On 2013-09-04 13:01, Nick Sabalausky wrote:
> > 
> >>> Requires Debian 7.0 or later. For Debian 6, install the the packages "gcc-multilib" and "ia32-libs".
> >>>
> >>
> >> I definitely have multilib on there since other stuff works 32-bit (like rdmd). It's just libcurl that I can't seem to get 32-bit or multilib.
> > 
> > I would be very surprised if libcurl isn't included in ia32-libs.
> > 
> 
> Yes, "ia32-libs" depends on "ia32-libs-i386:i386" which depends on "libcurl3:i386"
> 

It turns out I was missing "ia32-libs", however I just installed it an I'm still getting "cannot find -lcurl" (or something like that) from the linker. "gcc-multilib" is already installed, and again, 32-bit stuff that doesn't use libcurl works fine.

On Wed, 04 Sep 2013 09:16:38 +0200
Jacob Carlborg <doob@me.com> wrote:
> 
> * Mac OS X uses "dylib" as the extension for dynamic libraries
> 
> * On Mac OS X Xcode is required. It's possible to just download the command line tools but I don't think that has been verified to work
> 

Now fixed. I also added a -j,--jobs switch that passes through to GNU make on Posix (According to the --help screen, it looks like DM make doesn't support it).

On Wed, 4 Sep 2013 07:27:53 -0400
Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:

> On Wed, 04 Sep 2013 13:22:39 +0200
> Jacob Carlborg <doob@me.com> wrote:
> 
> > On 2013-09-04 13:16, Nick Sabalausky wrote:
> > 
> > > Actually, that's a good point, I have to double-check that. I don't remember adding any code to skip 64-bit on FreeBSD, *but* I was careful to make everything match the v2.063.2 release zip as closely as possible, so I might have omitted it under the assumption that "Well, this release zip doesn't have bin64 or lib64 for bsd, so I guess it's not considered ready for prime-time yet."
> > 
> > The latest release of DMD for FreeBSD only includes 32bit binaries.
> > 
> 
> Yea, that's why it's possible I might have excluded 64-bit for FreeBSD (and then forgot I did so). I'll check.

Just checked: The tool *is* set up to build and package 64-bit on FreeBSD (assuming the 32-bit stuff doesn't fail before it gets to the 64-bit pass).

On Wed, Sep 04, 2013 at 05:55:41PM -0400, Nick Sabalausky wrote:
> On Wed, 04 Sep 2013 13:54:35 +0200
> Jordi Sayol <g.sayol@yahoo.es> wrote:
> 
> > On 04/09/13 13:21, Jacob Carlborg wrote:
> > > On 2013-09-04 13:01, Nick Sabalausky wrote:
> > > 
> > >>> Requires Debian 7.0 or later. For Debian 6, install the the packages "gcc-multilib" and "ia32-libs".
> > >>>
> > >>
> > >> I definitely have multilib on there since other stuff works 32-bit (like rdmd). It's just libcurl that I can't seem to get 32-bit or multilib.
> > > 
> > > I would be very surprised if libcurl isn't included in ia32-libs.
> > > 
> > 
> > Yes, "ia32-libs" depends on "ia32-libs-i386:i386" which depends on "libcurl3:i386"
> > 
> 
> It turns out I was missing "ia32-libs", however I just installed it an I'm still getting "cannot find -lcurl" (or something like that) from the linker. "gcc-multilib" is already installed, and again, 32-bit stuff that doesn't use libcurl works fine.

Did you install libcurl*-dev? Debian lib packages generally only include runtime .so's; to get compile-time stuff you need the corresponding -dev packages.

And I'm not sure why, but it seems that in debian/unstable there are
multiple incompatible versions of libcurl-dev. The one I have is
libcurl4-openssl-dev, just FYI.


T

-- 
Turning your clock 15 minutes ahead won't cure lateness---you're just making time go faster!

I've noticed the you support MSVC builds but require some
environment variables to be set.  As part of my installer#22 pull
request[1] I worked out how to retrieve both the Visual C and SDK
paths from the registry.  You could retrieve them from there
instead of requiring environment variables if you'd like.
Obviously just getting everything working in the release
generator (great work, by the way) comes first but this would be
one less thing people would need to do before they can use it).



Visual Studio 12.0 (2013):
HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\12.0\Setup\VC\ProductDir
(libraries are in <productdir>\lib (32-bit) or
<productdir>\lib\amd64)

Visual Studio 11.0 (2012):
HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\11.0\Setup\VC\ProductDir
(libraries are in <productdir>\lib (32-bit) or
<productdir>\lib\amd64)

Visual Studio 10.0 (2013):
HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\10.0\Setup\VC\ProductDir
(libraries are in <productdir>\lib (32-bit) or
<productdir>\lib\amd64)



Windows Kit 8.1:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows Kits\Installed
Roots\KitsRoot81
(libraries are in <kitroot>\Lib\winv6.3\um\{x86,x64,arm})

Windows Kit 8.0:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows Kits\Installed
Roots\KitsRoot
(libraries are in <kitroot>\Lib\winv6.3\um\{x86,x64,arm})

Microsoft SDK 7.1A:
HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft
SDKs\Windows\v7.1A\InstallationFolder
(libraries are in <sdkroot>\Lib (32-bit) or <sdkroot>\Lib\x64)

Microsoft SDK 7.0A:
HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft
SDKs\Windows\v7.0A\InstallationFolder
(libraries are in <sdkroot>\Lib (32-bit) or <sdkroot>\Lib\x64)

1. https://github.com/D-Programming-Language/installer/pull/22

On Wed, 4 Sep 2013 16:01:32 -0700
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:

> On Wed, Sep 04, 2013 at 05:55:41PM -0400, Nick Sabalausky wrote:
> > 
> > It turns out I was missing "ia32-libs", however I just installed it an I'm still getting "cannot find -lcurl" (or something like that) from the linker. "gcc-multilib" is already installed, and again, 32-bit stuff that doesn't use libcurl works fine.
> 
> Did you install libcurl*-dev? Debian lib packages generally only include runtime .so's; to get compile-time stuff you need the corresponding -dev packages.
> 

Yea, I had already installed libcurl4-openssl-dev. I even removed it and reinstalled it after installing "ia32-libs". But still no dice.

On Wed, 04 Sep 2013 13:25:06 +0200
"Dicebot" <public@dicebot.lv> wrote:

> On Wednesday, 4 September 2013 at 11:23:53 UTC, Jacob Carlborg wrote:
> > On 2013-09-04 13:18, Nick Sabalausky wrote:
> >
> >> I think I just copy-pasted it from somewhere. It is really
> >> better to do
> >> the "git@github.com:blah/blah.git"?
> >
> > As far as I know, yes.
> 
> git:// is faster
> https:// is less likely to be blocked by various firewalls and
> filters
> 
> Choice is yours :)

Ok, in that case, it sounds like https is better for right now, but it would be good to have an optional flag to use git:// instead. Actually, maybe it should try git:// and if it fails, then try https://. But that can probably wait. The important thing is to get this working.