digitalmars.D - Need help to finish DMD zip/7z release generator (alpha release)
- Nick Sabalausky (60/60) Sep 03 2013 tl;dr: The main things I need help with: Installing 32-bit libcurl on
- Rikki Cattermole (7/96) Sep 03 2013 You have to manually tell dpkg that it can use specific
- Nick Sabalausky (12/19) Sep 03 2013 Eh, damn, it looks like I may need to put together a Debian 7 persistent
- Rikki Cattermole (10/36) Sep 03 2013 I think in the case of Debian based systems that having one for
- Jacob Carlborg (11/40) Sep 03 2013 I can test it on Mac OS X 10.8. Are you building a universal binary of
- Nick Sabalausky (10/49) Sep 04 2013 Great. :)
- Jacob Carlborg (4/10) Sep 04 2013 I would be very surprised if libcurl isn't included in ia32-libs.
- Nick Sabalausky (3/15) Sep 04 2013 Hmm, maybe I'm missing "ia32-libs" then. I'll check when I get a chance.
- Jordi Sayol (4/16) Sep 04 2013 Yes, "ia32-libs" depends on "ia32-libs-i386:i386" which depends on "libc...
- Nick Sabalausky (6/23) Sep 04 2013 It turns out I was missing "ia32-libs", however I just installed it an
- H. S. Teoh (11/36) Sep 04 2013 Did you install libcurl*-dev? Debian lib packages generally only include
- Nick Sabalausky (4/15) Sep 04 2013 Yea, I had already installed libcurl4-openssl-dev. I even removed it
- Jordi Sayol (7/26) Sep 05 2013 You need to install the 32-bit version of "libcurl4-openssl-dev", but du...
- H. S. Teoh (12/29) Sep 05 2013 Oh wait, you're complaining about 32-bit support, aren't you? You'll
- Jacob Carlborg (4/12) Sep 05 2013 That's only available on Debian 7 and later. He uses Debian 6.
- Jacob Carlborg (15/19) Sep 04 2013 A couple of issues/questions:
- Nick Sabalausky (26/46) Sep 04 2013 Thanks. Will fix.
- Jacob Carlborg (4/10) Sep 04 2013 The latest release of DMD for FreeBSD only includes 32bit binaries.
- Nick Sabalausky (4/15) Sep 04 2013 Yea, that's why it's possible I might have excluded 64-bit for FreeBSD
- Nick Sabalausky (5/23) Sep 04 2013 Just checked: The tool *is* set up to build and package 64-bit on
- Jacob Carlborg (4/9) Sep 05 2013 Why don't you use std.zip? Although I don't know if that handles symlink...
- Nick Sabalausky (8/19) Sep 05 2013 Judging by the doc page for that, it seems like 1. it's not quite as
- Jacob Carlborg (4/9) Sep 05 2013 Right, I thought I saw an API for reading/writing files as well.
- Nick Sabalausky (5/11) Sep 04 2013 Now fixed. I also added a -j,--jobs switch that passes through to GNU
- Jacob Carlborg (5/15) Sep 04 2013 I would be nice if I could pass the "-j" flag to make, or if it could do...
- Nick Sabalausky (4/9) Sep 04 2013 That's the "use X number of simultaneous processes" flag, right? Good
- Jacob Carlborg (4/6) Sep 04 2013 Yes.
- Jacob Carlborg (5/15) Sep 04 2013 Why are you using HTTPS when cloning and not SSH? If I'm not mistaken
- Nick Sabalausky (4/8) Sep 04 2013 I think I just copy-pasted it from somewhere. It is really better to do
- Jacob Carlborg (4/6) Sep 04 2013 As far as I know, yes.
- Dicebot (6/11) Sep 04 2013 git:// is faster
- Nick Sabalausky (6/21) Sep 04 2013 Ok, in that case, it sounds like https is better for right now, but it
- Jacob Carlborg (6/9) Sep 04 2013 As far as I can see, dmd.conf is missing. I used the following command:
- Nick Sabalausky (4/18) Sep 04 2013 [...]
- Nick Sabalausky (33/45) Sep 04 2013 They're in the built-in "extras":
- Jacob Carlborg (4/6) Sep 04 2013 Ok, I see.
- Jacob Carlborg (5/8) Sep 04 2013 When I unpack the generate zip none of the binaries have executable
- Nick Sabalausky (3/12) Sep 22 2013 Fixed.
- Brad Anderson (37/37) Sep 04 2013 I've noticed the you support MSVC builds but require some
- Nick Sabalausky (3/12) Sep 04 2013 Thanks, yea, that will be a good addition to this.
- Jacob Carlborg (17/22) Sep 05 2013 It tried the tool on FreeBSD (PC-BSD) 64bit. I got this error:
- Nick Sabalausky (8/33) Sep 05 2013 One of the tools (dman, IIRC) requires the docs to be built, and since
- Jacob Carlborg (4/7) Sep 05 2013 Yeah, that's will make things a lot easier.
- Nick Sabalausky (7/15) Sep 06 2013 Ok, I've just added optional switches --only-32 and --only-64. But I'm
- Nick Sabalausky (6/24) Sep 08 2013 The --combine-* flags now handle the 32-bit-only and 64-bit-only
- Nick Sabalausky (10/21) Sep 13 2013 That issue is still blocking the release generator (seems to be the
- Rainer Schuetze (43/64) Sep 13 2013 The generated sc.ini in dmd/src is no good, the LIB environment variable...
- Nick Sabalausky (23/76) Sep 14 2013 Ahh, ok I had been wondering about all of that, and even toyed around
- Rainer Schuetze (41/59) Sep 15 2013 Actually I could not reproduce this problem now. Could it be that this
- Nick Sabalausky (29/112) Sep 20 2013 Aha! That was it! I don't know why my experiments doing that didn't
- Rainer Schuetze (4/33) Sep 20 2013 I noticed that it is the git process that has a handle on that
- Nick Sabalausky (5/10) Sep 20 2013 Hmm, well it's been working fine on my Win machine as-is, but I'll look
- Nick Sabalausky (6/17) Sep 21 2013 Just before I was about to make that fix, I started experiencing the
- Rainer Schuetze (56/73) Sep 21 2013 I retried and had the issue with access to %TEMP%/".create_dmd_release
- Nick Sabalausky (17/58) Sep 25 2013 Yea, Windows is a pain with file/directory locking :/
- Paulo Pinto (9/18) Sep 25 2013 Well, actually Windows is way better than POSIX in this regard, because
- Nick Sabalausky (5/29) Sep 25 2013 Oh right, that's certainly true, which I why I have a bit of a
- Jacob Carlborg (6/7) Sep 25 2013 If I recall correctly, you can use JavaScript as an alternative. I would...
- PauloPinto (3/8) Sep 26 2013 Powershell :)
- Jacob Carlborg (5/6) Sep 26 2013 I have never used that for scripting so I have no idea how it is. Also,
- Paulo Pinto (6/10) Sep 26 2013 It is, since Windows Vista, everything else is anyway already in life
- Nick Sabalausky (3/37) Sep 28 2013 Should be fixed now.
- dennis luehring (3/13) Sep 13 2013 would it be nice to also include https://github.com/DigitalMars/optlink
- Nick Sabalausky (10/14) Sep 14 2013 Yes, but I wasn't sure how to handle selecting the version of optlink:
- Nick Sabalausky (5/13) Sep 28 2013 Thanks everyone for the help! All known problems have been addressed as
- Andrej Mitrovic (25/28) Oct 08 2013 Do you think we could resolve the outdated import lib issue with this
- Andrej Mitrovic (2/3) Oct 08 2013 *script
tl;dr: The main things I need help with: Installing 32-bit libcurl on 64-bit Debian, testing on 64-bit FreeBSD, and figuring out WTF is so screwed up on Windows. It's almost finished, but I've hit some problems I'm having a hell of a time figuring out. I'm getting a kinda brain-fried and need some help with it: Here's what I have right now (it's named "create_dmd_release"): https://github.com/Abscissa/installer/tree/create-zip The "how to" documentation is at the top of the source file: https://github.com/Abscissa/installer/blob/create-zip/create_dmd_release/create_dmd_release.d Important note for trying it out: -------------------------------------- This tool depends on itself actually being in the official repo. Since this hasn't actually been pulled in yet (I don't think it's ready for a pull request just yet), you will need one small change to the ahead and Ctrl-C kill it (or wait for it to end - either way). Then, copy the "create_dmd_release" directory tree into "[your temp dir]/.create_dmd_release/installer". You can check the temp dir it uses with "create_dmd_release --help". Finally, re-run the same original command, but add the flag "--skip-clone". DMD versions: ----------------------- This is intended for DMDs *after* v2.063.2, because it requires some changes in the "master" of the "tools" repo. However, you *can* coax it to work on v2.063.2 by halting it after the "clone" stage, then updating "[tmp-dir]/.create_dmd_release/tools/*.mak" with the latest versions from master, and then resuming the process by re-running with "--skip-clone". But additional hacking may be needed on Windows. The current status: ----------------------- - OSX 10.7: Works fine. (At least it did last time I tried it, a couple weeks ago. It *could* have regressed but I won't have access to the machine again until maybe Sunday.) - Debian 6 (32-bit OS): This tool isn't intended to support 32-bit OSes (since it must compile both 32-bit and 64-bit phobos), but it works fine up until it gets to the 64-bit stuff. If I manually comment out the 64-bit stuff, then everything else works fine. - Debian 6 (64-bit OS): It fails when linking the 32-bit phobos complaining that it can't link with libcurl. I'm fairly certain this is because I have no freaking idea how to install the 32-bit libcurl*-*-dev on a 64-bit Debian. (I *did* install "libcurl4-openssl-dev", but I'm pretty sure it only installed for 64-bit. And I can't figure out how to get the 32-bit.) - FreeBSD 9.1 (32-bit OS): Same as 32-bit Debian 6: It works, except for the 64-bit stuff. - FreeBSD 9.1 (64-bit OS): No idea, I don't have access to a 64-bit FreeBSD machine, and my stupid Intel CPU lacks the ability to run a 64-bit OS in a VM. - Windows 7 (64-bit OS): This is where I'm having the biggest trouble. I can coaxing it to handle v2.063.2 just fine (ie, if I update the "tools" makefiles as described above, and comment out all the "libcurl" and "chm" stuff.) However, on master, after it compiles DMD/druntime/phobos, the resulting DMD/phobos can't compile anything that uses phobos because OPTLINK will spew out a bunch of errors. I am *completely* at a loss on this one. It seems like an sc.ini issue, but I've spent days checking everything and I still can't make heads or tails of it.
Sep 03 2013
On Wednesday, 4 September 2013 at 00:53:14 UTC, Nick Sabalausky wrote:tl;dr: The main things I need help with: Installing 32-bit libcurl on 64-bit Debian, testing on 64-bit FreeBSD, and figuring out WTF is so screwed up on Windows. It's almost finished, but I've hit some problems I'm having a hell of a time figuring out. I'm getting a kinda brain-fried and need some help with it: Here's what I have right now (it's named "create_dmd_release"): https://github.com/Abscissa/installer/tree/create-zip The "how to" documentation is at the top of the source file: https://github.com/Abscissa/installer/blob/create-zip/create_dmd_release/create_dmd_release.d Important note for trying it out: -------------------------------------- This tool depends on itself actually being in the official repo. Since this hasn't actually been pulled in yet (I don't think it's ready for a pull request just yet), you will need one small change to the go ahead and Ctrl-C kill it (or wait for it to end - either way). Then, copy the "create_dmd_release" directory tree into "[your temp dir]/.create_dmd_release/installer". You can check the temp dir it uses with "create_dmd_release --help". Finally, re-run the same original command, but add the flag "--skip-clone". DMD versions: ----------------------- This is intended for DMDs *after* v2.063.2, because it requires some changes in the "master" of the "tools" repo. However, you *can* coax it to work on v2.063.2 by halting it after the "clone" stage, then updating "[tmp-dir]/.create_dmd_release/tools/*.mak" with the latest versions from master, and then resuming the process by re-running with "--skip-clone". But additional hacking may be needed on Windows. The current status: ----------------------- - OSX 10.7: Works fine. (At least it did last time I tried it, a couple weeks ago. It *could* have regressed but I won't have access to the machine again until maybe Sunday.) - Debian 6 (32-bit OS): This tool isn't intended to support 32-bit OSes (since it must compile both 32-bit and 64-bit phobos), but it works fine up until it gets to the 64-bit stuff. If I manually comment out the 64-bit stuff, then everything else works fine. - Debian 6 (64-bit OS): It fails when linking the 32-bit phobos complaining that it can't link with libcurl. I'm fairly certain this is because I have no freaking idea how to install the 32-bit libcurl*-*-dev on a 64-bit Debian. (I *did* install "libcurl4-openssl-dev", but I'm pretty sure it only installed for 64-bit. And I can't figure out how to get the 32-bit.) - FreeBSD 9.1 (32-bit OS): Same as 32-bit Debian 6: It works, except for the 64-bit stuff. - FreeBSD 9.1 (64-bit OS): No idea, I don't have access to a 64-bit FreeBSD machine, and my stupid Intel CPU lacks the ability to run a 64-bit OS in a VM. - Windows 7 (64-bit OS): This is where I'm having the biggest trouble. I can coaxing it to handle v2.063.2 just fine (ie, if I update the "tools" makefiles as described above, and comment out all the "libcurl" and "chm" stuff.) However, on master, after it compiles DMD/druntime/phobos, the resulting DMD/phobos can't compile anything that uses phobos because OPTLINK will spew out a bunch of errors. I am *completely* at a loss on this one. It seems like an sc.ini issue, but I've spent days checking everything and I still can't make heads or tails of it.You have to manually tell dpkg that it can use specific architectures like 32bit in a 64bit system [1]. However this takes a bit of configuration to get working so this might have to be left to the user and not placed into the script. [1] https://wiki.debian.org/Multiarch/HOWTO
Sep 03 2013
On Wed, 04 Sep 2013 04:18:37 +0200 "Rikki Cattermole" <alphaglosined gmail.com> wrote:You have to manually tell dpkg that it can use specific architectures like 32bit in a 64bit system [1]. However this takes a bit of configuration to get working so this might have to be left to the user and not placed into the script. [1] https://wiki.debian.org/Multiarch/HOWTOEh, damn, it looks like I may need to put together a Debian 7 persistent live disc/usb because I can't seem to get the necessary versions of dpkg/apt in Deb 6, even in backports. But...don't linux bins tend to not work on systems (ie, glibc) older than the one used to compile? If that's the case then maybe I should make the 32- and 64-bit passes separable so a multilib system isn't required (which appears to mandate very new versions of linux, at least for debian anyway). What kind of linux system is currently being used to generate the linux releases?
Sep 03 2013
On Wednesday, 4 September 2013 at 04:15:38 UTC, Nick Sabalausky wrote:On Wed, 04 Sep 2013 04:18:37 +0200 "Rikki Cattermole" <alphaglosined gmail.com> wrote:I think in the case of Debian based systems that having one for 32bit and 64bit might work. However don't quote me on that. I took a look at Ubuntu's support and its very similar to Debian's. "In Debian dpkg this is present since 1.16.2. In Ubuntu this is present since natty (v1.15.8.10ubuntu1)." That may be of some use to you. Thats for multiarch support. I can't really help much more than this I'm afraid.You have to manually tell dpkg that it can use specific architectures like 32bit in a 64bit system [1]. However this takes a bit of configuration to get working so this might have to be left to the user and not placed into the script. [1] https://wiki.debian.org/Multiarch/HOWTOEh, damn, it looks like I may need to put together a Debian 7 persistent live disc/usb because I can't seem to get the necessary versions of dpkg/apt in Deb 6, even in backports. But...don't linux bins tend to not work on systems (ie, glibc) older than the one used to compile? If that's the case then maybe I should make the 32- and 64-bit passes separable so a multilib system isn't required (which appears to mandate very new versions of linux, at least for debian anyway). What kind of linux system is currently being used to generate the linux releases?
Sep 03 2013
On 2013-09-04 02:53, Nick Sabalausky wrote:The current status: ----------------------- - OSX 10.7: Works fine. (At least it did last time I tried it, a couple weeks ago. It *could* have regressed but I won't have access to the machine again until maybe Sunday.)I can test it on Mac OS X 10.8. Are you building a universal binary of the libraries?- Debian 6 (32-bit OS): This tool isn't intended to support 32-bit OSes (since it must compile both 32-bit and 64-bit phobos), but it works fine up until it gets to the 64-bit stuff. If I manually comment out the 64-bit stuff, then everything else works fine.Why don't you just version that out?- Debian 6 (64-bit OS): It fails when linking the 32-bit phobos complaining that it can't link with libcurl. I'm fairly certain this is because I have no freaking idea how to install the 32-bit libcurl*-*-dev on a 64-bit Debian. (I *did* install "libcurl4-openssl-dev", but I'm pretty sure it only installed for 64-bit. And I can't figure out how to get the 32-bit.)Using "apt-get install package:architecture" as suggested here: https://wiki.debian.org/Multiarch/HOWTO Requires Debian 7.0 or later. For Debian 6, install the the packages "gcc-multilib" and "ia32-libs".- FreeBSD 9.1 (32-bit OS): Same as 32-bit Debian 6: It works, except for the 64-bit stuff. - FreeBSD 9.1 (64-bit OS): No idea, I don't have access to a 64-bit FreeBSD machine, and my stupid Intel CPU lacks the ability to run a 64-bit OS in a VM.I can give you a help with this, if no one else beats me.- Windows 7 (64-bit OS): This is where I'm having the biggest trouble. I can coaxing it to handle v2.063.2 just fine (ie, if I update the "tools" makefiles as described above, and comment out all the "libcurl" and "chm" stuff.) However, on master, after it compiles DMD/druntime/phobos, the resulting DMD/phobos can't compile anything that uses phobos because OPTLINK will spew out a bunch of errors. I am *completely* at a loss on this one. It seems like an sc.ini issue, but I've spent days checking everything and I still can't make heads or tails of it.-- /Jacob Carlborg
Sep 03 2013
On Wed, 04 Sep 2013 08:33:28 +0200 Jacob Carlborg <doob me.com> wrote:On 2013-09-04 02:53, Nick Sabalausky wrote:Great. :)The current status: ----------------------- - OSX 10.7: Works fine. (At least it did last time I tried it, a couple weeks ago. It *could* have regressed but I won't have access to the machine again until maybe Sunday.)I can test it on Mac OS X 10.8.Are you building a universal binary of the libraries?Yes.I'm thinking I may just add --32-bit(-only) and --64-bit(-only) switches.- Debian 6 (32-bit OS): This tool isn't intended to support 32-bit OSes (since it must compile both 32-bit and 64-bit phobos), but it works fine up until it gets to the 64-bit stuff. If I manually comment out the 64-bit stuff, then everything else works fine.Why don't you just version that out?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.- Debian 6 (64-bit OS): It fails when linking the 32-bit phobos complaining that it can't link with libcurl. I'm fairly certain this is because I have no freaking idea how to install the 32-bit libcurl*-*-dev on a 64-bit Debian. (I *did* install "libcurl4-openssl-dev", but I'm pretty sure it only installed for 64-bit. And I can't figure out how to get the 32-bit.)Using "apt-get install package:architecture" as suggested here: https://wiki.debian.org/Multiarch/HOWTO Requires Debian 7.0 or later. For Debian 6, install the the packages "gcc-multilib" and "ia32-libs".Cool.- FreeBSD 9.1 (64-bit OS): No idea, I don't have access to a 64-bit FreeBSD machine, and my stupid Intel CPU lacks the ability to run a 64-bit OS in a VM.I can give you a help with this, if no one else beats me.
Sep 04 2013
On 2013-09-04 13:01, Nick Sabalausky wrote:I would be very surprised if libcurl isn't included in ia32-libs. -- /Jacob CarlborgRequires 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.
Sep 04 2013
On Wed, 04 Sep 2013 13:21:06 +0200 Jacob Carlborg <doob me.com> wrote:On 2013-09-04 13:01, Nick Sabalausky wrote:Hmm, maybe I'm missing "ia32-libs" then. I'll check when I get a chance.I would be very surprised if libcurl isn't included in ia32-libs.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.
Sep 04 2013
On 04/09/13 13:21, Jacob Carlborg wrote:On 2013-09-04 13:01, Nick Sabalausky wrote:Yes, "ia32-libs" depends on "ia32-libs-i386:i386" which depends on "libcurl3:i386" -- Jordi SayolI would be very surprised if libcurl isn't included in ia32-libs.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.
Sep 04 2013
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: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 2013-09-04 13:01, Nick Sabalausky wrote:Yes, "ia32-libs" depends on "ia32-libs-i386:i386" which depends on "libcurl3:i386"I would be very surprised if libcurl isn't included in ia32-libs.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.
Sep 04 2013
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: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!On 04/09/13 13:21, Jacob Carlborg 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.On 2013-09-04 13:01, Nick Sabalausky wrote:Yes, "ia32-libs" depends on "ia32-libs-i386:i386" which depends on "libcurl3:i386"I would be very surprised if libcurl isn't included in ia32-libs.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.
Sep 04 2013
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:Yea, I had already installed libcurl4-openssl-dev. I even removed it and reinstalled it after installing "ia32-libs". But still no dice.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.
Sep 04 2013
On 05/09/13 07:25, Nick Sabalausky wrote:On Wed, 4 Sep 2013 16:01:32 -0700 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote:You need to install the 32-bit version of "libcurl4-openssl-dev", but due to dependencies this will force to replace "pkg-config:amd64" by "pkg-config:i386", because cannot have both 32-bit and 64-bit installed at same time. The easiest way to do it is just create a symlink to the already installed shared curl library. With "libcurl3:i386" installed, you can try this: $ sudo ln -s libcurl.so.4 /usr/lib/i386-linux-gnu/libcurl.so -- Jordi SayolOn Wed, Sep 04, 2013 at 05:55:41PM -0400, Nick Sabalausky wrote:Yea, I had already installed libcurl4-openssl-dev. I even removed it and reinstalled it after installing "ia32-libs". But still no dice.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.
Sep 05 2013
On Thu, Sep 05, 2013 at 01:25:21AM -0400, Nick Sabalausky wrote:On Wed, 4 Sep 2013 16:01:32 -0700 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote:Oh wait, you're complaining about 32-bit support, aren't you? You'll need to: dpkg --add-architecture i386 apt-get update apt-get install libcurl4-openssl-dev:i386 Under Debian multiarch, packages for different architectures are installed separately, so you have to explicitly install the same package for both architectures if you need it for both. T -- People say I'm indecisive, but I'm not sure about that. -- YHL, CONLANGOn Wed, Sep 04, 2013 at 05:55:41PM -0400, Nick Sabalausky wrote:Yea, I had already installed libcurl4-openssl-dev. I even removed it and reinstalled it after installing "ia32-libs". But still no dice.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.
Sep 05 2013
On 2013-09-05 16:57, H. S. Teoh wrote:Oh wait, you're complaining about 32-bit support, aren't you? You'll need to: dpkg --add-architecture i386 apt-get update apt-get install libcurl4-openssl-dev:i386 Under Debian multiarch, packages for different architectures are installed separately, so you have to explicitly install the same package for both architectures if you need it for both.That's only available on Debian 7 and later. He uses Debian 6. -- /Jacob Carlborg
Sep 05 2013
On 2013-09-04 02:53, Nick Sabalausky wrote:Here's what I have right now (it's named "create_dmd_release"): https://github.com/Abscissa/installer/tree/create-zip The "how to" documentation is at the top of the source file: https://github.com/Abscissa/installer/blob/create-zip/create_dmd_release/create_dmd_release.dA couple of issues/questions: * 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 * " --combine-zip (Posix-only) Combine all platform-specific archives in current directory into cross-platform zip archive. Cannot be used on Windows because the symlinks would be destroyed. Implies --skip-package." Can't zip for Windows handle symlinks? Windows Vista (I think) and later supports symlinks. * The extra files should be put under version control * Does this builds a release for FreeBSD 64bit? If not, it should -- /Jacob Carlborg
Sep 04 2013
On Wed, 04 Sep 2013 09:16:38 +0200 Jacob Carlborg <doob me.com> wrote:A couple of issues/questions: * Mac OS X uses "dylib" as the extension for dynamic librariesThanks. Will fix.* 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 workI'll make a note in the docs section.* " --combine-zip (Posix-only) Combine all platform-specific archives in current directory into cross-platform zip archive. Cannot be used on Windows because the symlinks would be destroyed. Implies --skip-package." Can't zip for Windows handle symlinks? Windows Vista (I think) and later supports symlinks.In an attempt to keep the platform differences as minimal as possible, I have it set up to automatically download and use Info-ZIP and 7zip on Windows, the same programs typically used on Posix. Unfortunately, these did not appear to handle symlinks correctly. Anyone know of one I could use that does?* The extra files should be put under version controlI agree, and I did do that with some of them (<https://github.com/Abscissa/installer/tree/create-zip/create_dmd_release/extras>). But for other files I wasn't sure whether there might be any potential rights/license issues, or issues with sticking binary files up on github (my understanding is that git isn't particularly efficient with binaries). So I didn't want to jump the gun on that unless we had an official OK on all such files. If any of those other files do get ok'ed for version control, then they can simply be added to the proper OS subdirectory under <https://github.com/Abscissa/installer/tree/create-zip/create_dmd_release/extras> and it should "just work".* Does this builds a release for FreeBSD 64bit? If not, it shouldActually, 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."
Sep 04 2013
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. -- /Jacob Carlborg
Sep 04 2013
On Wed, 04 Sep 2013 13:22:39 +0200 Jacob Carlborg <doob me.com> wrote:On 2013-09-04 13:16, Nick Sabalausky wrote:Yea, that's why it's possible I might have excluded 64-bit for FreeBSD (and then forgot I did so). I'll check.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.
Sep 04 2013
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: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 2013-09-04 13:16, Nick Sabalausky wrote:Yea, that's why it's possible I might have excluded 64-bit for FreeBSD (and then forgot I did so). I'll check.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.
Sep 04 2013
On 2013-09-04 13:16, Nick Sabalausky wrote:In an attempt to keep the platform differences as minimal as possible, I have it set up to automatically download and use Info-ZIP and 7zip on Windows, the same programs typically used on Posix. Unfortunately, these did not appear to handle symlinks correctly. Anyone know of one I could use that does?Why don't you use std.zip? Although I don't know if that handles symlinks. -- /Jacob Carlborg
Sep 05 2013
On Thu, 05 Sep 2013 13:36:09 +0200 Jacob Carlborg <doob me.com> wrote:On 2013-09-04 13:16, Nick Sabalausky wrote:Judging by the doc page for that, it seems like 1. it's not quite as mature as Info-ZIP, and 2. It doesn't actually read/write files directly, just does the in-memory part. Naturally, I could still use it and use std.file for the i/o, but I'm not sure it would be worth the bother for this. It may very well be worth attempting later though.In an attempt to keep the platform differences as minimal as possible, I have it set up to automatically download and use Info-ZIP and 7zip on Windows, the same programs typically used on Posix. Unfortunately, these did not appear to handle symlinks correctly. Anyone know of one I could use that does?Why don't you use std.zip? Although I don't know if that handles symlinks.
Sep 05 2013
On 2013-09-05 22:02, Nick Sabalausky wrote:Judging by the doc page for that, it seems like 1. it's not quite as mature as Info-ZIP, and 2. It doesn't actually read/write files directly, just does the in-memory part. Naturally, I could still use it and use std.file for the i/o, but I'm not sure it would be worth the bother for this.Right, I thought I saw an API for reading/writing files as well. -- /Jacob Carlborg
Sep 05 2013
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 workNow 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).
Sep 04 2013
On 2013-09-04 02:53, Nick Sabalausky wrote:tl;dr: The main things I need help with: Installing 32-bit libcurl on 64-bit Debian, testing on 64-bit FreeBSD, and figuring out WTF is so screwed up on Windows. It's almost finished, but I've hit some problems I'm having a hell of a time figuring out. I'm getting a kinda brain-fried and need some help with it: Here's what I have right now (it's named "create_dmd_release"): https://github.com/Abscissa/installer/tree/create-zip The "how to" documentation is at the top of the source file: https://github.com/Abscissa/installer/blob/create-zip/create_dmd_release/create_dmd_release.dI would be nice if I could pass the "-j" flag to make, or if it could do that automatically. It can save quite a lot of time when compiling DMD. -- /Jacob Carlborg
Sep 04 2013
On Wed, 04 Sep 2013 09:48:08 +0200 Jacob Carlborg <doob me.com> wrote:I would be nice if I could pass the "-j" flag to make, or if it could do that automatically. It can save quite a lot of time when compiling DMD.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.
Sep 04 2013
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
Sep 04 2013
On 2013-09-04 02:53, Nick Sabalausky wrote:tl;dr: The main things I need help with: Installing 32-bit libcurl on 64-bit Debian, testing on 64-bit FreeBSD, and figuring out WTF is so screwed up on Windows. It's almost finished, but I've hit some problems I'm having a hell of a time figuring out. I'm getting a kinda brain-fried and need some help with it: Here's what I have right now (it's named "create_dmd_release"): https://github.com/Abscissa/installer/tree/create-zip The "how to" documentation is at the top of the source file: https://github.com/Abscissa/installer/blob/create-zip/create_dmd_release/create_dmd_release.dWhy are you using HTTPS when cloning and not SSH? If I'm not mistaken the latter is faster. -- /Jacob Carlborg
Sep 04 2013
On Wed, 04 Sep 2013 10:01:02 +0200 Jacob Carlborg <doob me.com> wrote:Why are you using HTTPS when cloning and not SSH? If I'm not mistaken the latter is faster.I think I just copy-pasted it from somewhere. It is really better to do the "git github.com:blah/blah.git"?
Sep 04 2013
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. -- /Jacob Carlborg
Sep 04 2013
On Wednesday, 4 September 2013 at 11:23:53 UTC, Jacob Carlborg wrote:On 2013-09-04 13:18, Nick Sabalausky wrote:git:// is faster https:// is less likely to be blocked by various firewalls and filters Choice is yours :)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.
Sep 04 2013
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: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.On 2013-09-04 13:18, Nick Sabalausky wrote:git:// is faster https:// is less likely to be blocked by various firewalls and filters Choice is yours :)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.
Sep 04 2013
On 2013-09-04 02:53, Nick Sabalausky wrote:- OSX 10.7: Works fine. (At least it did last time I tried it, a couple weeks ago. It *could* have regressed but I won't have access to the machine again until maybe Sunday.)As far as I can see, dmd.conf is missing. I used the following command: ./create_dmd_release master --extras=./dmd-localextras/localextras-osx --archive-zip -- /Jacob Carlborg
Sep 04 2013
On Wed, 04 Sep 2013 10:01:28 +0200 Jacob Carlborg <doob me.com> wrote:On 2013-09-04 02:53, Nick Sabalausky wrote:[...]- OSX 10.7: Works fine. (At least it did last time I tried it, a couple weeks ago. It *could* have regressed but I won't have access to the machine again until maybe Sunday.)As far as I can see, dmd.conf is missing. I used the following command: ./create_dmd_release master --extras=./dmd-localextras/localextras-osx --archive-zipWhen I unpack the generate zip none of the binaries have executable permission set.Thanks, I'll check into both of those.
Sep 04 2013
On Wed, 04 Sep 2013 10:01:28 +0200 Jacob Carlborg <doob me.com> wrote:On 2013-09-04 02:53, Nick Sabalausky wrote:They're in the built-in "extras": <https://github.com/Abscissa/installer/tree/create-zip/create_dmd_release/extras/osx/dmd2/osx/bin> The short answer is: "That problem only happens because create_dmd_release isn't in the official github repo yet". Long answer and workaround: When create_dmd_release clones all the repos from github, everything inside the *cloned* "installer/create_dmd_release/extras/all" and "installer/create_dmd_release/extras/[current os]" will be automatically added to the release (During the "package" phase, it grabs these "extras" from the cloned "create_dmd_release" *instead* of from the copy of "create_dmd_release" being run so the "extras" files can be different for different releases of DMD). But since create_dmd_release, and the attached "extras", hasn't yet been merged into the official "D-Programming-Language/installer" repo, you're missing that "extras" directory, including the dmd.conf files. When create_dmd_release is all official and merged in, that won't be an issue. But until then, you have to stop the process after it clones everything, manually copy the "create_dmd_release/extras" directory to "[temp]/.create_dmd_release/installer/create_dmd_release/extras" and then re-run create_dmd_release with the --skip-clone flag. Or better yet, instead of halting create_dmd_release, copying "extras", and re-runnnig with --skip-clone (which is kind of a pain), you could just copy the contents of both "installer/create_dmd_release/extras/all" and "installer/create_dmd_release/extras/[current os]" into your "localextras-[current os]". That will work too. But again, this work around is *only* needed because create_dmd_release isn't in the official github repo yet. I *could* add an option to specify an alternate repo to clone, but I'm not sure it's worth it since it would become useless as soon as this gets merged.- OSX 10.7: Works fine. (At least it did last time I tried it, a couple weeks ago. It *could* have regressed but I won't have access to the machine again until maybe Sunday.)As far as I can see, dmd.conf is missing. I used the following command: ./create_dmd_release master --extras=./dmd-localextras/localextras-osx --archive-zip
Sep 04 2013
On 2013-09-05 07:56, Nick Sabalausky wrote:The short answer is: "That problem only happens because create_dmd_release isn't in the official github repo yet".Ok, I see. -- /Jacob Carlborg
Sep 04 2013
On 2013-09-04 02:53, Nick Sabalausky wrote:- OSX 10.7: Works fine. (At least it did last time I tried it, a couple weeks ago. It *could* have regressed but I won't have access to the machine again until maybe Sunday.)When I unpack the generate zip none of the binaries have executable permission set. -- /Jacob Carlborg
Sep 04 2013
On Wed, 04 Sep 2013 10:13:48 +0200 Jacob Carlborg <doob me.com> wrote:On 2013-09-04 02:53, Nick Sabalausky wrote:Fixed.- OSX 10.7: Works fine. (At least it did last time I tried it, a couple weeks ago. It *could* have regressed but I won't have access to the machine again until maybe Sunday.)When I unpack the generate zip none of the binaries have executable permission set.
Sep 22 2013
I've noticed the you support MSVC builds but require some 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
Sep 04 2013
On Thu, 05 Sep 2013 02:34:36 +0200 "Brad Anderson" <eco gnuk.net> wrote:I've noticed the you support MSVC builds but require some 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).Thanks, yea, that will be a good addition to this.
Sep 04 2013
On Wednesday, 4 September 2013 at 00:53:14 UTC, Nick Sabalausky wrote:- FreeBSD 9.1 (64-bit OS): No idea, I don't have access to a 64-bit FreeBSD machine, and my stupid Intel CPU lacks the ability to run a 64-bit OS in a VM.It tried the tool on FreeBSD (PC-BSD) 64bit. I got this error: Building Tools 64-bit std.md5 is scheduled for deprecation. Please use std.digest.md instead gmake: *** No rule to make target `../dlang.org/web/expression.html', needed by `expression.tag'. Stop. create_dmd_release: Error: Command failed (ran from dir '/tmp/.create_dmd_release/tools'): gmake MODEL=64 dman DMD=../dmd/src/dmd DOC=../dlang.org/web PHOBOSDOC=../dlang.org/web/phobos -f posix.mak > /dev/null I don't know if it's me that did something wrong or if it's your tool. I had to disable the 32bit builds. -- /Jacob Carlborg
Sep 05 2013
On Thu, 05 Sep 2013 21:56:25 +0200 "Jacob Carlborg" <doob me.com> wrote:On Wednesday, 4 September 2013 at 00:53:14 UTC, Nick Sabalausky wrote:One of the tools (dman, IIRC) requires the docs to be built, and since the docs are independent of 32/64-bit, they're built during the 32-bit pass (which you skipped). I've decided I'm going to add proper support for 32-bit-only and 64-bit-only via optional cmdline flags. That should make a lot of things easier and help mitigate difficulties with multilib.- FreeBSD 9.1 (64-bit OS): No idea, I don't have access to a 64-bit FreeBSD machine, and my stupid Intel CPU lacks the ability to run a 64-bit OS in a VM.It tried the tool on FreeBSD (PC-BSD) 64bit. I got this error: Building Tools 64-bit std.md5 is scheduled for deprecation. Please use std.digest.md instead gmake: *** No rule to make target `../dlang.org/web/expression.html', needed by `expression.tag'. Stop. create_dmd_release: Error: Command failed (ran from dir '/tmp/.create_dmd_release/tools'): gmake MODEL=64 dman DMD=../dmd/src/dmd DOC=../dlang.org/web PHOBOSDOC=../dlang.org/web/phobos -f posix.mak > /dev/null I don't know if it's me that did something wrong or if it's your tool. I had to disable the 32bit builds.
Sep 05 2013
On 2013-09-05 22:07, Nick Sabalausky wrote:I've decided I'm going to add proper support for 32-bit-only and 64-bit-only via optional cmdline flags. That should make a lot of things easier and help mitigate difficulties with multilib.Yeah, that's will make things a lot easier. -- /Jacob Carlborg
Sep 05 2013
On Fri, 06 Sep 2013 08:45:29 +0200 Jacob Carlborg <doob me.com> wrote:On 2013-09-05 22:07, Nick Sabalausky wrote:Ok, I've just added optional switches --only-32 and --only-64. But I'm heading out right now so I didn't test it very well, and the --combine-* flags currently ignore the new non-multilib archives generated by those switches. I'll probably be able to take care of those later tonight, but hopefully this should make things easier.I've decided I'm going to add proper support for 32-bit-only and 64-bit-only via optional cmdline flags. That should make a lot of things easier and help mitigate difficulties with multilib.Yeah, that's will make things a lot easier.
Sep 06 2013
On Fri, 6 Sep 2013 17:59:41 -0400 Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:On Fri, 06 Sep 2013 08:45:29 +0200 Jacob Carlborg <doob me.com> wrote:The --combine-* flags now handle the 32-bit-only and 64-bit-only archives correctly. I've also adjusted it to clone using the git protocol, and automatically fallback to https if that fails.On 2013-09-05 22:07, Nick Sabalausky wrote:Ok, I've just added optional switches --only-32 and --only-64. But I'm heading out right now so I didn't test it very well, and the --combine-* flags currently ignore the new non-multilib archives generated by those switches. I'll probably be able to take care of those later tonight, but hopefully this should make things easier.I've decided I'm going to add proper support for 32-bit-only and 64-bit-only via optional cmdline flags. That should make a lot of things easier and help mitigate difficulties with multilib.Yeah, that's will make things a lot easier.
Sep 08 2013
On Tue, 3 Sep 2013 20:53:11 -0400 Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:- Windows 7 (64-bit OS): This is where I'm having the biggest trouble. I can coaxing it to handle v2.063.2 just fine (ie, if I update the "tools" makefiles as described above, and comment out all the "libcurl" and "chm" stuff.) However, on master, after it compiles DMD/druntime/phobos, the resulting DMD/phobos can't compile anything that uses phobos because OPTLINK will spew out a bunch of errors. I am *completely* at a loss on this one. It seems like an sc.ini issue, but I've spent days checking everything and I still can't make heads or tails of it.That issue is still blocking the release generator (seems to be the same issue at least one other person was already having): http://d.puremagic.com/issues/show_bug.cgi?id=10729 Can anyone who is able to build a *working* 32-bit DMD/phobos from master on Windows pop into that issue page and see what this does for them?: mkdir junk create_dmd_release master --extras=junk --only-32 -v
Sep 13 2013
On 13.09.2013 23:31, Nick Sabalausky wrote:On Tue, 3 Sep 2013 20:53:11 -0400 Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:The generated sc.ini in dmd/src is no good, the LIB environment variable should be set like this: LIB="% P%\..\..\phobos" Even if you do so, it does not work because optlink is also looking for an sc.ini (contrary or in addition to the documentation that mentions optlink.cfg) and extracts the LIB environment variable. If the link.exe in the PATH is from a different version of dmd, the wrong phobos.lib is taken. It is easiest to always put link.exe into the same directory as dmd.exe. While you are at it, I'd recommend an sc.ini that looks about like this in the release: ; environment for both 32/64 bit [Environment] LIB="% P%\..\lib" DFLAGS="-I% P%\..\..\src\phobos" "-I% P%\..\..\src\druntime\import" LINKCMD=% P%\link.exe [Environment64] ; VS2008 and VS2012 LINKCMD64=%VCINSTALLDIR%\bin\amd64\link.exe ; VS2012 ; LINKCMD64=%VCINSTALLDIR%\bin\x86_amd64\link.exe ; needed with /DEBUG to find mspdb*.dll PATH=%PATH%;%VCINSTALLDIR%\bin\x86_amd64;%VCINSTALLDIR%\..\Common7\IDE ; needed to avoid COMDAT folding (bugzilla 10664) DFLAGS=%DFLAGS% -L/OPT:NOICF LIB="% P%\..\lib64" ;;;; search path for C Runtime libraries ; the following lib path works with VS2008, VS2010 and VS2012 LIB=%LIB%;"%VCINSTALLDIR%\lib\amd64" ;;;; search path for Platform libraries ; the following lib path works with Windows SDK 6.x and 7.x LIB=%LIB%;%WindowsSdkDir%\Lib\x64 ; the following lib path works with Windows SDK 8.0 LIB=%LIB%;%WindowsSdkDir%\Lib\win8\um\x64 This includes the install of win64 libraries into a lib64 folder instead of mixing it with OMF libraries in the lib folder. 3 more nitpicks: - the working directory defaultWorkDir is never created - I get an error that '.' cannot be removed, but I can continue answering 'n' to the following question for retry - my copies of the Windows SDKs 6 and 7 don't have folders License, Redist, Samples and Setup. I would just skip these tests.- Windows 7 (64-bit OS): This is where I'm having the biggest trouble. I can coaxing it to handle v2.063.2 just fine (ie, if I update the "tools" makefiles as described above, and comment out all the "libcurl" and "chm" stuff.) However, on master, after it compiles DMD/druntime/phobos, the resulting DMD/phobos can't compile anything that uses phobos because OPTLINK will spew out a bunch of errors. I am *completely* at a loss on this one. It seems like an sc.ini issue, but I've spent days checking everything and I still can't make heads or tails of it.That issue is still blocking the release generator (seems to be the same issue at least one other person was already having): http://d.puremagic.com/issues/show_bug.cgi?id=10729 Can anyone who is able to build a *working* 32-bit DMD/phobos from master on Windows pop into that issue page and see what this does for them?: mkdir junk create_dmd_release master --extras=junk --only-32 -v
Sep 13 2013
On Sat, 14 Sep 2013 08:32:04 +0200 Rainer Schuetze <r.sagitario gmx.de> wrote:On 13.09.2013 23:31, Nick Sabalausky wrote:Ahh, ok I had been wondering about all of that, and even toyed around with those changes, but I still couldn't get it to work. But by then, I had already been reduced to kinda tossing around theories semi-randomly, so maybe I still messed it up. I'll try again - at least this time I know ;)On Tue, 3 Sep 2013 20:53:11 -0400 Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:The generated sc.ini in dmd/src is no good, the LIB environment variable should be set like this: LIB="% P%\..\..\phobos" Even if you do so, it does not work because optlink is also looking for an sc.ini (contrary or in addition to the documentation that mentions optlink.cfg) and extracts the LIB environment variable. If the link.exe in the PATH is from a different version of dmd, the wrong phobos.lib is taken. It is easiest to always put link.exe into the same directory as dmd.exe.- Windows 7 (64-bit OS): This is where I'm having the biggest trouble. I can coaxing it to handle v2.063.2 just fine (ie, if I update the "tools" makefiles as described above, and comment out all the "libcurl" and "chm" stuff.) However, on master, after it compiles DMD/druntime/phobos, the resulting DMD/phobos can't compile anything that uses phobos because OPTLINK will spew out a bunch of errors. I am *completely* at a loss on this one. It seems like an sc.ini issue, but I've spent days checking everything and I still can't make heads or tails of it.That issue is still blocking the release generator (seems to be the same issue at least one other person was already having): http://d.puremagic.com/issues/show_bug.cgi?id=10729 Can anyone who is able to build a *working* 32-bit DMD/phobos from master on Windows pop into that issue page and see what this does for them?: mkdir junk create_dmd_release master --extras=junk --only-32 -vWhile you are at it, I'd recommend an sc.ini that looks about like this in the release: [...]Thanks, I'll update it.3 more nitpicks: - the working directory defaultWorkDir is never createdReally? Hmm: - Is it possible that might be a permissions issue? Since this isn't really an end-user tool, I didn't feel a need to make sure it worked with a limited user account. What temp directory is reported when you do "create_dmd_release --help"? - Are you using --use-clone=path? If so, then it won't create defaultWorkDir unless it needs to - although I might have missed something there, so I'll check into that.- I get an error that '.' cannot be removed, but I can continue answering 'n' to the following question for retryOk now that seems bizarre. Can you post a log or screenshot of that? I have no idea what part of the process might be doing that - definitely something involving an external tool being invoked, because I didn't add any interactive prompts to it. You're not running it *from* the [your temp dir]/.create_dmd_release directory, are you?- my copies of the Windows SDKs 6 and 7 don't have folders License, Redist, Samples and Setup. I would just skip these tests.Ok.
Sep 14 2013
On 14.09.2013 21:30, Nick Sabalausky wrote:Actually I could not reproduce this problem now. Could it be that this happened with a version from a few days ago and was already fixed?Really? Hmm: - Is it possible that might be a permissions issue? Since this isn't really an end-user tool, I didn't feel a need to make sure it worked with a limited user account. What temp directory is reported when you do "create_dmd_release --help"? - Are you using --use-clone=path? If so, then it won't create defaultWorkDir unless it needs to - although I might have missed something there, so I'll check into that.3 more nitpicks: - the working directory defaultWorkDir is never createdI using an user account with Admin rights. Here is what I do up to the error: C:\tmp\d\installer\create_dmd_release>set path=c:\l\dmd2.063\windows\bin;c:\l\dmc\bin;%path% C:\tmp\d\installer\create_dmd_release>dmd create_dmd_release.d C:\tmp\d\installer\create_dmd_release>md x C:\tmp\d\installer\create_dmd_release>cd x C:\tmp\d\installer\create_dmd_release\x>md junk C:\tmp\d\installer\create_dmd_release\x>..\create_dmd_release master --extras=junk --only-32 -v Checking: git --help Checking: unzip --help Checking: zip -v Checking: 7za --help Checking: dmc -c .create_release_dummy Checking: make -f .create_release_dummy Running: dmc .create_release_dummy.c -L/? > .create_release_optlink_help Checking: type .create_release_optlink_help Checking: type .create_release_optlink_help Creating dir: C:\Users\Rainer\AppData\Local\Temp\.create_dmd_release Entering dir: C:\Users\Rainer\AppData\Local\Temp\.create_dmd_release Creating dir: dmd Entering dir: dmd Cloning: git github.com:D-Programming-Language/dmd.git Running: git clone "git github.com:D-Programming-Language/dmd.git" . Cloning into '.'... Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Deletion of directory '.' failed. Should I try again? (y/n) n Entering dir: C:\Users\Rainer\AppData\Local\Temp\.create_dmd_release Couldn't do git protocol, falling back to 'https://'... Removing dir: dmd Creating dir: dmd Entering dir: dmd Cloning: https://github.com/D-Programming-Language/dmd.git ...Ok now that seems bizarre. Can you post a log or screenshot of that? I have no idea what part of the process might be doing that - definitely something involving an external tool being invoked, because I didn't add any interactive prompts to it. You're not running it*from* the [your temp dir]/.create_dmd_release directory, are you?- I get an error that '.' cannot be removed, but I can continue answering 'n' to the following question for retry
Sep 15 2013
On Sat, 14 Sep 2013 08:32:04 +0200 Rainer Schuetze <r.sagitario gmx.de> wrote:The generated sc.ini in dmd/src is no good, the LIB environment variable should be set like this: LIB="% P%\..\..\phobos" Even if you do so, it does not work because optlink is also looking for an sc.ini (contrary or in addition to the documentation that mentions optlink.cfg) and extracts the LIB environment variable. If the link.exe in the PATH is from a different version of dmd, the wrong phobos.lib is taken. It is easiest to always put link.exe into the same directory as dmd.exe.Aha! That was it! I don't know why my experiments doing that didn't work before (I must have messed up something else at the time), but fixing sc.ini and copying OPTLINK to the same dir fixed that problem! I still have another small issue with the chm generation, and some thorough testing to do, but things are looking REALLY good now!That turned out to be a regression I had introduced with a recent change. I didn't catch it because, for me, the directory was already there. It went away for you because the directory must have gotten created on another run. It's fixed on GitHub now.Actually I could not reproduce this problem now. Could it be that this happened with a version from a few days ago and was already fixed?Really? Hmm: - Is it possible that might be a permissions issue? Since this isn't really an end-user tool, I didn't feel a need to make sure it worked with a limited user account. What temp directory is reported when you do "create_dmd_release --help"? - Are you using --use-clone=path? If so, then it won't create defaultWorkDir unless it needs to - although I might have missed something there, so I'll check into that.- the working directory defaultWorkDir is never createdOk, I see what's happening. It's git that's doing that: This create_dmd_release tool *tries* to clone using git/ssh protocol because it's supposed to be faster, albeit less compatible. But if that fails (as it does for both you and me...some rights/certificate issue apparently), then the script tries again using the slower, but more reliable HTTPS protocol. But here's the thing: When git tries to clone, and the clone fails, then git's nice about it and tries to clean up the mess it left behind by deleting the directory with the failed clone. Unfortunately, Windows likes to randomly hold file locks open (or maybe it's a bug in your version of git that's holding an old file handle open). So git's unable to delete the failed-clone directory and asks if you want to try again. I can't find a cmdline switch to tell "git clone" to always retry (or to never retry), so I don't think there's much create_dmd_release can do about it, short of reading git's output, scanning for that question, and sending a 'y'. But that seems like overkill. It may be better to just let people answer on their own if they get that.I using an user account with Admin rights. Here is what I do up to the error: C:\tmp\d\installer\create_dmd_release>set path=c:\l\dmd2.063\windows\bin;c:\l\dmc\bin;%path% C:\tmp\d\installer\create_dmd_release>dmd create_dmd_release.d C:\tmp\d\installer\create_dmd_release>md x C:\tmp\d\installer\create_dmd_release>cd x C:\tmp\d\installer\create_dmd_release\x>md junk C:\tmp\d\installer\create_dmd_release\x>..\create_dmd_release master --extras=junk --only-32 -v Checking: git --help Checking: unzip --help Checking: zip -v Checking: 7za --help Checking: dmc -c .create_release_dummy Checking: make -f .create_release_dummy Running: dmc .create_release_dummy.c -L/?Ok now that seems bizarre. Can you post a log or screenshot of that? I have no idea what part of the process might be doing that - definitely something involving an external tool being invoked, because I didn't add any interactive prompts to it. You're not running it*from* the [your temp dir]/.create_dmd_release directory, are you?- I get an error that '.' cannot be removed, but I can continue answering 'n' to the following question for retry.create_release_optlink_help Checking: type .create_release_optlink_helpChecking: type .create_release_optlink_help Creating dir: C:\Users\Rainer\AppData\Local\Temp\.create_dmd_release Entering dir: C:\Users\Rainer\AppData\Local\Temp\.create_dmd_release Creating dir: dmd Entering dir: dmd Cloning: git github.com:D-Programming-Language/dmd.git Running: git clone "git github.com:D-Programming-Language/dmd.git" . Cloning into '.'... Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Deletion of directory '.' failed. Should I try again? (y/n) n Entering dir: C:\Users\Rainer\AppData\Local\Temp\.create_dmd_release Couldn't do git protocol, falling back to 'https://'... Removing dir: dmd Creating dir: dmd Entering dir: dmd Cloning: https://github.com/D-Programming-Language/dmd.git ...
Sep 20 2013
On 20.09.2013 09:29, Nick Sabalausky wrote:I noticed that it is the git process that has a handle on that directory. It seems to able to delete the directory if you run git from the parent directory and pass "dmd" instead of ".".fatal: Could not read from remote repository.Ok, I see what's happening. It's git that's doing that: This create_dmd_release tool*tries* to clone using git/ssh protocol because it's supposed to be faster, albeit less compatible. But if that fails (as it does for both you and me...some rights/certificate issue apparently), then the script tries again using the slower, but more reliable HTTPS protocol. But here's the thing: When git tries to clone, and the clone fails, then git's nice about it and tries to clean up the mess it left behind by deleting the directory with the failed clone. Unfortunately, Windows likes to randomly hold file locks open (or maybe it's a bug in your version of git that's holding an old file handle open). So git's unable to delete the failed-clone directory and asks if you want to try again. I can't find a cmdline switch to tell "git clone" to always retry (or to never retry), so I don't think there's much create_dmd_release can do about it, short of reading git's output, scanning for that question, and sending a 'y'. But that seems like overkill. It may be better to just let people answer on their own if they get that.Please make sure you have the correct access rights and the repository exists. Deletion of directory '.' failed. Should I try again? (y/n) n Entering dir: C:\Users\Rainer\AppData\Local\Temp\.create_dmd_release Couldn't do git protocol, falling back to 'https://'... Removing dir: dmd Creating dir: dmd Entering dir: dmd Cloning:https://github.com/D-Programming-Language/dmd.git ...
Sep 20 2013
On Fri, 20 Sep 2013 21:38:06 +0200 Rainer Schuetze <r.sagitario gmx.de> wrote:On 20.09.2013 09:29, Nick Sabalausky wrote: I noticed that it is the git process that has a handle on that directory. It seems to able to delete the directory if you run git from the parent directory and pass "dmd" instead of ".".Hmm, well it's been working fine on my Win machine as-is, but I'll look into doing that. I think I had some reason for doing it this way, but it probably wasn't anything major.
Sep 20 2013
On Fri, 20 Sep 2013 17:39:22 -0400 Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:On Fri, 20 Sep 2013 21:38:06 +0200 Rainer Schuetze <r.sagitario gmx.de> wrote:Just before I was about to make that fix, I started experiencing the same problem, too. I've made the change you suggested and it seems to work for me. Can you verify?I noticed that it is the git process that has a handle on that directory. It seems to able to delete the directory if you run git from the parent directory and pass "dmd" instead of ".".Hmm, well it's been working fine on my Win machine as-is, but I'll look into doing that. I think I had some reason for doing it this way, but it probably wasn't anything major.
Sep 21 2013
On 22.09.2013 04:54, Nick Sabalausky wrote:On Fri, 20 Sep 2013 17:39:22 -0400 Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:I retried and had the issue with access to %TEMP%/".create_dmd_release problem problem during startup again. This time it was TortoiseGitCache holding a handle to that directory. Killing that process helped. Then, the 32-bit build ran flawlessly if I - add the dmc binary path to the PATH environment variable - add the path to some existing dmd installation to the path. rdmd is needed to run get_dlibcurl32.bat. [OT: I noticed it uses a VB script to do the download. Shudder ;-) Here is a http-get function without needing curl: https://github.com/D-Programming-Language/visuald/blob/master/stdext/httpget.d , though I don't know how usable it is. ] I usually don't have these paths added because the folders contain too many executables that try to replace more useful versions of them (lib,link,shell,make). I'd prefer if you could specify the path to dmc as an option, but it's not a big deal as the task of building the release is pretty special anyway. It would be nice if rdmd is used from the current build, though. After the successful build I tried the 64-bit build. It stopped here: Building Druntime 64-bit Entering dir: C:\Users\Rainer\AppData\Local\Temp\.create_dmd_release\druntime Running: make MODEL=64 DMD=../dmd/src/dmd -f win64.mak mkdir import\core\stdc A subdirectory or file import\core\stdc already exists. mkdir import\core\sys\freebsd\sys A subdirectory or file import\core\sys\freebsd\sys already exists. mkdir import\core\sys\linux\sys A subdirectory or file import\core\sys\linux\sys already exists. mkdir import\core\sys\osx\mach A subdirectory or file import\core\sys\osx\mach already exists. mkdir import\core\sys\posix\arpa A subdirectory or file import\core\sys\posix\arpa already exists. mkdir import\core\sys\posix\net A subdirectory or file import\core\sys\posix\net already exists. mkdir import\core\sys\posix\netinet A subdirectory or file import\core\sys\posix\netinet already exists. mkdir import\core\sys\posix\sys A subdirectory or file import\core\sys\posix\sys already exists. mkdir import\core\sys\windows A subdirectory or file import\core\sys\windows already exists. mkdir import\etc\linux A subdirectory or file import\etc\linux already exists. "\Program Files (x86)\Microsoft Visual Studio 10.0\VC"\bin\amd64\cl -c /Z7 /I"\Program Files (x86)\Microsoft Visual Studio 10.0\VC"\INCLUDE /I"\Program Files (x86)\Microsoft SDKs\Windows\v7.0A"\Include src\core\stdc\errno.c -Foerrno_c.obj Error: '\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\amd64\cl' not found Entering dir: C:\tmp\d\installer2\create_dmd_release\x create_dmd_release: Error: Command failed (ran from dir 'C:\Users\Rainer\AppData\Local\Temp\.create_dmd_release\druntime'): make MODEL=64 DMD=../dmd/src/dmd -f win64.mak This happens because the VCDIR variable is not passed to the makefile (to work with VS2012+ you'll have to pass CC and AR explicitely as the path to the binaries inside the VS installation has changed).On Fri, 20 Sep 2013 21:38:06 +0200 Rainer Schuetze <r.sagitario gmx.de> wrote:Just before I was about to make that fix, I started experiencing the same problem, too. I've made the change you suggested and it seems to work for me. Can you verify?I noticed that it is the git process that has a handle on that directory. It seems to able to delete the directory if you run git from the parent directory and pass "dmd" instead of ".".Hmm, well it's been working fine on my Win machine as-is, but I'll look into doing that. I think I had some reason for doing it this way, but it probably wasn't anything major.
Sep 21 2013
On Sun, 22 Sep 2013 08:59:04 +0200 Rainer Schuetze <r.sagitario gmx.de> wrote:I retried and had the issue with access to %TEMP%/".create_dmd_release problem problem during startup again. This time it was TortoiseGitCache holding a handle to that directory. Killing that process helped.Yea, Windows is a pain with file/directory locking :/[OT: I noticed it uses a VB script to do the download. Shudder ;-) Here is a http-get function without needing curl: https://github.com/D-Programming-Language/visuald/blob/master/stdext/httpget.d , though I don't know how usable it is. ]I admit, the VBScript thing is a bit of a hack. On the upside, the actual connection/dload is handled by a lib that's been in Windows for some time, so hopefully it should be pretty battle-hardened. I'll definitely keep yours in mind in the future, I think that's awesome to have. But in the interest of getting this (and some other things) out the door I think I'll keep it as-is for now.I usually don't have these paths added because the folders contain too many executables that try to replace more useful versions of them (lib,link,shell,make). I'd prefer if you could specify the path to dmc as an option, but it's not a big deal as the task of building the release is pretty special anyway.It's a nice idea, but as you say it's not real critical right now.It would be nice if rdmd is used from the current build, though.Agreed, and now fixed.After the successful build I tried the 64-bit build. It stopped here: Building Druntime 64-bit Entering dir: C:\Users\Rainer\AppData\Local\Temp\.create_dmd_release\druntime Running: make MODEL=64 DMD=../dmd/src/dmd -f win64.mak [...] "\Program Files (x86)\Microsoft Visual Studio 10.0\VC"\bin\amd64\cl -c /Z7 /I"\Program Files (x86)\Microsoft Visual Studio 10.0\VC"\INCLUDE /I"\Program Files (x86)\Microsoft SDKs\Windows\v7.0A"\Include src\core\stdc\errno.c -Foerrno_c.obj Error: '\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\amd64\cl' not found Entering dir: C:\tmp\d\installer2\create_dmd_release\x create_dmd_release: Error: Command failed (ran from dir 'C:\Users\Rainer\AppData\Local\Temp\.create_dmd_release\druntime'): make MODEL=64 DMD=../dmd/src/dmd -f win64.mak This happens because the VCDIR variable is not passed to the makefile (to work with VS2012+ you'll have to pass CC and AR explicitely as the path to the binaries inside the VS installation has changed).Ugh, I wish MS would just pick a design as stick with it :/... I'll try to take care of that. On the bright side though, this *should* be the final critical issue blocking create_dmd_release from meeting its basic charter and being "pull request"-ready. Everything else seems to be working fine now on Windows and various Posixen in all my tests so far, so fingers crossed...
Sep 25 2013
On 25.09.2013 15:36, Nick Sabalausky wrote:On Sun, 22 Sep 2013 08:59:04 +0200 Rainer Schuetze <r.sagitario gmx.de> wrote:Well, actually Windows is way better than POSIX in this regard, because Windows like a few other systems does implement locking at the kernel level. Whereas POSIX locking relies in a form of userspace cooperative locking that does not prevent someone to come in between and mess up with the files. Nothing like deleting a file or write to it, while it is in use by other processes, without any means to prevent such actions in a portable way. -- PauloI retried and had the issue with access to %TEMP%/".create_dmd_release problem problem during startup again. This time it was TortoiseGitCache holding a handle to that directory. Killing that process helped.Yea, Windows is a pain with file/directory locking :/
Sep 25 2013
On Wed, 25 Sep 2013 16:58:48 +0200 Paulo Pinto <pjmlp progtools.org> wrote:On 25.09.2013 15:36, Nick Sabalausky wrote:Oh right, that's certainly true, which I why I have a bit of a love/hate thing for how Windows does it. It's safer and more "correct", but also frequently a big pain. Stoopid tradeoffs...On Sun, 22 Sep 2013 08:59:04 +0200 Rainer Schuetze <r.sagitario gmx.de> wrote:Well, actually Windows is way better than POSIX in this regard, because Windows like a few other systems does implement locking at the kernel level. Whereas POSIX locking relies in a form of userspace cooperative locking that does not prevent someone to come in between and mess up with the files. Nothing like deleting a file or write to it, while it is in use by other processes, without any means to prevent such actions in a portable way.I retried and had the issue with access to %TEMP%/".create_dmd_release problem problem during startup again. This time it was TortoiseGitCache holding a handle to that directory. Killing that process helped.Yea, Windows is a pain with file/directory locking :/
Sep 25 2013
On 2013-09-25 15:36, Nick Sabalausky wrote:I admit, the VBScript thing is a bit of a hack.If I recall correctly, you can use JavaScript as an alternative. I would consider that slightly better. It would of course be better if both could be avoided. -- /Jacob Carlborg
Sep 25 2013
On Thursday, 26 September 2013 at 06:25:17 UTC, Jacob Carlborg wrote:On 2013-09-25 15:36, Nick Sabalausky wrote:Powershell :)I admit, the VBScript thing is a bit of a hack.If I recall correctly, you can use JavaScript as an alternative. I would consider that slightly better. It would of course be better if both could be avoided.
Sep 26 2013
On 2013-09-26 13:37, PauloPinto wrote:Powershell :)I have never used that for scripting so I have no idea how it is. Also, it's not installed by default, at least not on all versions of Windows. -- /Jacob Carlborg
Sep 26 2013
Am 26.09.2013 16:53, schrieb Jacob Carlborg:On 2013-09-26 13:37, PauloPinto wrote:It is, since Windows Vista, everything else is anyway already in life support. But it requires some learning effort, that's true. -- PauloPowershell :)I have never used that for scripting so I have no idea how it is. Also, it's not installed by default, at least not on all versions of Windows.
Sep 26 2013
On Wed, 25 Sep 2013 09:36:51 -0400 Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:On Sun, 22 Sep 2013 08:59:04 +0200 Rainer Schuetze <r.sagitario gmx.de> wrote:Should be fixed now.After the successful build I tried the 64-bit build. It stopped here: Building Druntime 64-bit Entering dir: C:\Users\Rainer\AppData\Local\Temp\.create_dmd_release\druntime Running: make MODEL=64 DMD=../dmd/src/dmd -f win64.mak [...] "\Program Files (x86)\Microsoft Visual Studio 10.0\VC"\bin\amd64\cl -c /Z7 /I"\Program Files (x86)\Microsoft Visual Studio 10.0\VC"\INCLUDE /I"\Program Files (x86)\Microsoft SDKs\Windows\v7.0A"\Include src\core\stdc\errno.c -Foerrno_c.obj Error: '\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\amd64\cl' not found Entering dir: C:\tmp\d\installer2\create_dmd_release\x create_dmd_release: Error: Command failed (ran from dir 'C:\Users\Rainer\AppData\Local\Temp\.create_dmd_release\druntime'): make MODEL=64 DMD=../dmd/src/dmd -f win64.mak This happens because the VCDIR variable is not passed to the makefile (to work with VS2012+ you'll have to pass CC and AR explicitely as the path to the binaries inside the VS installation has changed).Ugh, I wish MS would just pick a design as stick with it :/... I'll try to take care of that. On the bright side though, this *should* be the final critical issue blocking create_dmd_release from meeting its basic charter and being "pull request"-ready. Everything else seems to be working fine now on Windows and various Posixen in all my tests so far, so fingers crossed...
Sep 28 2013
Am 04.09.2013 02:53, schrieb Nick Sabalausky:tl;dr: The main things I need help with: Installing 32-bit libcurl on 64-bit Debian, testing on 64-bit FreeBSD, and figuring out WTF is so screwed up on Windows. It's almost finished, but I've hit some problems I'm having a hell of a time figuring out. I'm getting a kinda brain-fried and need some help with it: Here's what I have right now (it's named "create_dmd_release"): https://github.com/Abscissa/installer/tree/create-zip The "how to" documentation is at the top of the source file: https://github.com/Abscissa/installer/blob/create-zip/create_dmd_release/create_dmd_release.dwould it be nice to also include https://github.com/DigitalMars/optlink build?
Sep 13 2013
On Sat, 14 Sep 2013 08:41:53 +0200 dennis luehring <dl.soluz gmx.net> wrote:would it be nice to also include https://github.com/DigitalMars/optlink build?Yes, but I wasn't sure how to handle selecting the version of optlink: For packaging the latest new version of DMD, then yea, the latest optlink should probably be chosen. But for earlier versions of DMD, shouldn't it grab the same version of optlink that had originally come with it? If so, how? By requiring Walter to add dmd release tags to optlink just like for dmd/phobos/druntime/etc? By manually maintaining a table somewhere to lookup the proper oplink commit for a given DMD version?
Sep 14 2013
On Tue, 3 Sep 2013 20:53:11 -0400 Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:tl;dr: The main things I need help with: Installing 32-bit libcurl on 64-bit Debian, testing on 64-bit FreeBSD, and figuring out WTF is so screwed up on Windows. It's almost finished, but I've hit some problems I'm having a hell of a time figuring out. I'm getting a kinda brain-fried and need some help with it:Thanks everyone for the help! All known problems have been addressed as the pull request is here for standard destruction: https://github.com/D-Programming-Language/installer/pull/24
Sep 28 2013
On 9/29/13, Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:Thanks everyone for the help! All known problems have been addressed as the pull request is here for standard destruction: https://github.com/D-Programming-Language/installer/pull/24Do you think we could resolve the outdated import lib issue with this scrip? (http://d.puremagic.com/issues/show_bug.cgi?id=6625) dnewbie commented that he uses this approach when installing DMD: cd $path_to_dmd_lib% coffimplib "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib\advapi32.lib" advapi32.lib coffimplib "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib\comctl32.lib" comctl32.lib coffimplib "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib\comdlg32.lib" comdlg32.lib coffimplib "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib\gdi32.lib" gdi32.lib coffimplib "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib\kernel32.lib" kernel32.lib coffimplib "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib\shell32.lib" shell32.lib coffimplib "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib\shlwapi.lib" shlwapi.lib coffimplib "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib\user32.lib" user32.lib coffimplib "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib\ws2_32.lib" ws2_32.lib coffimplib "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib\wsock32.lib" wsock32.lib
Oct 08 2013
On 10/8/13, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:scrip*script
Oct 08 2013