[D-runtime] [D-Programming-Language/druntime] cef9bd: changes to build and pass unittests

[Brad Roberts]

On Saturday, November 24, 2012 2:40:32 AM, Rainer Schuetze wrote:
> On 11/24/2012 9:43 AM, Brad Roberts wrote:
>> On 11/24/2012 12:03 AM, Rainer Schuetze wrote:
>>>
>>> Cool. I was hitting this problem aswell, but didn't know what to do about it.
>>>
>>>> 3) remove -L/co and add user32.lib to unittest build command
>>>
>>> I think the root problem here is that windows.d forwards CreateWindowA to CreateWindowExA, producing code where only
>>> declarations are expected. It just adds unexpected DLL dependencies. Do you know why this is done?
>>>
>>> BTW: At the same time I noticed that most of the functions in windows.d are decorated with "export". Isn't this
>>> unnecessary and misleading?
>>
>> I know very little about the windows side of d, as I really don't use windows for anything other than getting to other
>> machines and it's office suite.  I decided to lend Walter a hand with getting the alpha up to the point of being ready
>> for auto-testing (it's not quite there yet, but it's close).  For any windows 'why' question(s), I'm a poor resource.
>>
>
> From the git-history, it seems that Sean did the initial commit that already included the code, so maybe he can comment.
>
>> I also don't intend to spend a lot of time coming up to speed on the issues.  My todo list is way too long already and
>> investing in improving a platform I don't use isn't enough to add it, sorry.
>>
>
> I'm also trying to push the win64 builds through the unittests and the test suite. To avoid duplication of efforts we
> should synchronize. I'm currently trying to convert my recent changes into pull requests...
>
> If you could setup the auto-tester to build for win64 that would be great.

The current blocker is getting phobos to build.  I'm using a windows server 2012 box (an ec2 instance).  When I stopped
last night there were two issues I was playing with:

1) std\algorithm.d -- can't build with -unittest without running out of process space (I need to try that hack to snn.lib)

2) When linking the unittest?.obj's together at the end:
    unittest6.obj : fatal error LNK1143: invalid or corrupt file: no symbol for COMDAT section 0x7FFF

I took unittest6.obj and broke it into 6a..6l, that version compiled and linked just fine.  I haven't yet started
digging deeper.

Oh, and the last thing that pushed me into choosing sleep vs doing more.. I need to get and build libcurl for win64.
Not hard, hopefully, but I didn't want to start a new phase fearing that I'd end up seeing the sunrise from the wrong
side of the clock.  If you've already got a curl.lib and .dll pair you can just hand to me (and to walter for the
website like we do for win32 already), that'd be handy.

I'd really like to get _a_ run to pass, even with a bunch of ugly hacks and/or tests disabled.  That gets to a point
where the test run can complete successfully and any regressions are obvious.  It does mean that there's things to clean
back up and tests to fix and re-enable.

I consider that the minimum starting point, and we're very close to it.  Actually getting it interacting with the
auto-tester is trivial (update acls, add rows to some tables (one day I'll write an admin interface for that), and
update web pages).