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

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

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.

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.

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

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.

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?

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?

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.

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