www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Need help to finish DMD zip/7z release generator (alpha release)

reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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
next sibling parent reply "Rikki Cattermole" <alphaglosined gmail.com> writes:
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
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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/HOWTO


Eh, 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
parent "Rikki Cattermole" <alphaglosined gmail.com> writes:
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:

 
 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


 Eh, 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?


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.
Sep 03 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 04 Sep 2013 08:33:28 +0200
Jacob Carlborg <doob me.com> wrote:


 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.


Great. :)


 Are you building a universal binary
 of the libraries?
 


Yes.


 - 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'm thinking I may just add --32-bit(-only) and --64-bit(-only)
switches.


 - 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".
 


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.



 - 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.
 


Cool.
Sep 04 2013
parent reply Jacob Carlborg <doob me.com> writes:
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.

-- 
/Jacob Carlborg
Sep 04 2013
next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 04 Sep 2013 13:21:06 +0200
Jacob Carlborg <doob me.com> 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.
 


Hmm, maybe I'm missing "ia32-libs" then. I'll check when I get a chance.
Sep 04 2013
prev sibling parent reply Jordi Sayol <g.sayol yahoo.es> writes:
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
Sep 04 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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.
Sep 04 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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!
Sep 04 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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.
Sep 04 2013
next sibling parent Jordi Sayol <g.sayol yahoo.es> writes:
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:
 

 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.
 
 


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 Sayol
Sep 05 2013
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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:
 

 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.


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, CONLANG
Sep 05 2013
parent Jacob Carlborg <doob me.com> writes:
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
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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.d


A 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
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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 libraries
 


Thanks. 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 work
 


I'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 control
 


I 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 should
 


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."
Sep 04 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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.
Sep 04 2013
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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).
Sep 04 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
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
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 05 Sep 2013 13:36:09 +0200
Jacob Carlborg <doob me.com> wrote:


 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.
 


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.
Sep 05 2013
parent Jacob Carlborg <doob me.com> writes:
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
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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).
Sep 04 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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.d


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.

-- 
/Jacob Carlborg
Sep 04 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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
parent Jacob Carlborg <doob me.com> writes:
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
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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.d


Why are you using HTTPS when cloning and not SSH? If I'm not mistaken 
the latter is faster.

-- 
/Jacob Carlborg
Sep 04 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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
parent reply Jacob Carlborg <doob me.com> writes:
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
parent reply "Dicebot" <public dicebot.lv> writes:
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 :)
Sep 04 2013
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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.
Sep 04 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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-zip
 


[...]

When I unpack the generate zip none of the binaries have executable 
permission set.


Thanks, I'll check into both of those.
Sep 04 2013
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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-zip
 


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.
Sep 04 2013
parent Jacob Carlborg <doob me.com> writes:
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
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 04 Sep 2013 10:13:48 +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.)


 
 When I unpack the generate zip none of the binaries have executable 
 permission set.
 


Fixed.
Sep 22 2013
prev sibling next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
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
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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
prev sibling next sibling parent reply "Jacob Carlborg" <doob me.com> writes:
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
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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:
 

 - 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.
 


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.
Sep 05 2013
parent reply Jacob Carlborg <doob me.com> writes:
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
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Fri, 06 Sep 2013 08:45:29 +0200
Jacob Carlborg <doob me.com> wrote:


 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.
 


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.
Sep 06 2013
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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:
 

 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.
 


 
 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.
 


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.
Sep 08 2013
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 13.09.2013 23:31, Nick Sabalausky wrote:

 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


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.
Sep 13 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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:

 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


 
 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.
 


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 ;)



 While 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 created


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.



 - I get an error that '.' cannot be removed, but I can continue 
 answering 'n' to the following question for retry


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?



 - 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
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 14.09.2013 21:30, Nick Sabalausky wrote:

3 more nitpicks:
- the working directory defaultWorkDir is never created




 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.


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?


- I get an error that '.' cannot be removed, but I can continue
answering 'n' to the following question for retry




 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 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
...
Sep 15 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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!



- the working directory defaultWorkDir is never created




 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.


 
 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?
 


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.



- I get an error that '.' cannot be removed, but I can continue
answering 'n' to the following question for retry




 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 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, 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.
Sep 20 2013
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 20.09.2013 09:29, Nick Sabalausky wrote:

 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, 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 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 ".".
Sep 20 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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:

 
 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.
 


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?
Sep 21 2013
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 22.09.2013 04:54, Nick Sabalausky wrote:

 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:

 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.


 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 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).
Sep 21 2013
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
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:

 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 :/


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.

--
Paulo
Sep 25 2013
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Wed, 25 Sep 2013 16:58:48 +0200
Paulo Pinto <pjmlp progtools.org> wrote:


 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:

 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 :/


 
 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.
 


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...
Sep 25 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
parent reply "PauloPinto" <pjmlp progtools.org> writes:
On Thursday, 26 September 2013 at 06:25:17 UTC, Jacob Carlborg 
wrote:

 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.


Powershell :)
Sep 26 2013
parent reply Jacob Carlborg <doob me.com> writes:
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
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 26.09.2013 16:53, schrieb Jacob Carlborg:

 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.


It is, since Windows Vista, everything else is anyway already in life 
support.

But it requires some learning effort, that's true.

--
Paulo
Sep 26 2013
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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:

 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...
 
 


Should be fixed now.
Sep 28 2013
prev sibling next sibling parent reply dennis luehring <dl.soluz gmx.net> writes:
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.d


would it be nice to also include https://github.com/DigitalMars/optlink 
build?
Sep 13 2013
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
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
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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/24


Do 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
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 10/8/13, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:

 scrip


*script
Oct 08 2013