Need help to finish DMD zip/7z release generator (alpha release)

Nick Sabalausky SeeWebsiteToContactMe at semitwist.com
Fri Sep 20 00:29:29 PDT 2013


On Sat, 14 Sep 2013 08:32:04 +0200
Rainer Schuetze <r.sagitario at 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 at github.com:D-Programming-Language/dmd.git
> Running: git clone "git at 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.



More information about the Digitalmars-d mailing list