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

[Rainer Schuetze]

On 11/24/2012 11:37 PM, Brad Roberts wrote:
> 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.

I'm not using the windows makefiles for some time now. I think adding 
another one is going into the wrong direction. Instead we should agree 
on a sensible version of gmake for windows and tweak the posix Makefiles 
to build on windows as well.

Still, the use case of building all of phobos into a single executable 
to detect circular imports seems sensible, but it could be performed on 
other platforms aswell.

>
> 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 ignored libcurl for now. I'll look into it later.

> 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 agree, showing a broken build due to win64 breaking on purpose might 
not be good idea.

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