Branch: refs/heads/master
  Home:   https://github.com/D-Programming-Language/druntime
  Commit: cef9bd58376f9b669fd8a329a99069e4996f9b89
      https://github.com/D-Programming-Language/druntime/commit/cef9bd58376f9b669fd8a329a99069e4996f9b89
  Author: Brad Roberts <braddr@puremagic.com>
  Date:   2012-11-23 (Fri, 23 Nov 2012)

  Changed paths:
    M src/core/bitop.d
    M src/core/thread.d
    M win64.mak

  Log Message:
  -----------
  changes to build and pass unittests

1) temporarily disable fibre tests
2) fix core.bitops.bitswap to understand win64 calling convention
3) remove -L/co and add user32.lib to unittest build command


  Commit: f19509c3670d39b97935021c5658fedc4e69779a
      https://github.com/D-Programming-Language/druntime/commit/f19509c3670d39b97935021c5658fedc4e69779a
  Author: Walter Bright <walter@walterbright.com>
  Date:   2012-11-23 (Fri, 23 Nov 2012)

  Changed paths:
    M src/core/bitop.d
    M src/core/thread.d
    M win64.mak

  Log Message:
  -----------
  Merge pull request #355 from braddr/win64-changes

changes to build and pass unittests


Compare: https://github.com/D-Programming-Language/druntime/compare/0937b40b318c...f19509c3670d

On 11/23/2012 9:15 PM, GitHub wrote:
>    Branch: refs/heads/master
>    Home:   https://github.com/D-Programming-Language/druntime
>    Commit: cef9bd58376f9b669fd8a329a99069e4996f9b89
>        https://github.com/D-Programming-Language/druntime/commit/cef9bd58376f9b669fd8a329a99069e4996f9b89
>    Author: Brad Roberts <braddr@puremagic.com>
>    Date:   2012-11-23 (Fri, 23 Nov 2012)
>
>    Changed paths:
>      M src/core/bitop.d
>      M src/core/thread.d
>      M win64.mak
>
>    Log Message:
>    -----------
>    changes to build and pass unittests
>
> 1) temporarily disable fibre tests
> 2) fix core.bitops.bitswap to understand win64 calling convention

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?

_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

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.

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.
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

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.
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

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

_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

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


_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime