On Saturday, 8 December 2018 at 03:25:46 UTC, Jonathan M Davis wrote:
> On Friday, December 7, 2018 8:09:37 PM MST Rubn via Digitalmars-d wrote:
>> On Saturday, 8 December 2018 at 02:08:14 UTC, Jonathan M Davis wrote:
>> > On Friday, December 7, 2018 3:15:30 PM MST Rubn via
>> >> This is part of the problem, in that there are more tests run on Linux than Windows. DMD doesn't even compile it self on Windows to test. It does for linux though. Also some of the community projects are all compiled and tested on linux but not windows. That's the state it is in, the only tests that are run are the most basic ones. Can't expect DMD on Windows to be stable at all, if ever that's the way it goes though I guess. No one seems to care or thinks running tests on linux only is good enough for windows.
>> >
>> > The entire test suite for druntime, Phobos, and dmd has to pass on all supported platforms on the auto-tester:
>> >
>> > https://auto-tester.puremagic.com/
>> >
>> > Windows is not exempt from that. So, unless there are a bunch of tests in the test suite which are needlessly platform-specific, Windows is getting tested just as much as Linux is. Where do you get the idea that it's not?
>> >
>> > - Jonathan M Davis
>>
>> https://ci.dlang.io/blue/organizations/jenkins/dlang-org%2Fdmd/detail/PR-8 519/3/pipeline
>>
>> I guess that's just another dead project, so I guess no platform is getting those tests anymore. Too bad, I guess that's another story for D, unless they moved to something else.
>
> I think that they moved those tests to buildkite, but I don't know what the exact situation with that is right now.

That's correct. Buildkite is a lot easier to work with then Jenkins.
Here's the overview page for the dlang pipelines:

https://buildkite.com/dlang


> While the main auto-tester has been the same for ages, they keep changing what they're doing with the other tests.

Yeah, we use too many resources for any of the free CIs to handle it. Though it looks like our current move to Buildkite was a good one and we can unify a few services under it - though as long as no one actually has Windows or OSX machines, that will be hard.

> But I believe that the tests for each project are run using travis and depend on how each project set that up, so which which platforms they test is going to vary from project to project. And I don't think that that includes Windows at all, because that would require something like appveyor.

We use Appveyor for DMD and druntime, though we keep running into the limit there too.

> So, the testing of projects beyond dmd and the standard library is only on *nix systems AFAIK, but dmd itself and the standard library are definitely tested on all of the platforms that dmd supports.

Yup, as mentioned currently we just don't have any Windows nor OSX machines to hook up with Buildkite.

>> What you linked are just those basic tests, those tests don't do anything complicated like building DMD itself with the newly created DMD and running the tests for both to ensure a correct binary is produced.
>
> The new compiler is built and used to run the druntime and Phobos test suites. Then it's used with the newly built druntime and Phobos to run the dmd test suite. So, the new dmd binary is definitely being tested, but no, the newly built dmd isn't then used to build dmd yet again as part of those tests.

This bootstrapping is tested (though not on the Auto-Tester). That's e.g. what we do with SemaphoreCI.

On Wednesday, 19 December 2018 at 11:32:58 UTC, Andre Pany wrote:
> On Saturday, 8 December 2018 at 15:04:12 UTC, Guillaume Piolat wrote:
>> On Friday, 7 December 2018 at 13:23:54 UTC, Andre Pany wrote:
>>>
>>> Visual studio is no longer needed as lld and x86mscoff/x86_64 libraries now included in dmd and LDC:)
>>>
>>> We just need to get it mature.
>>>
>>> Kind regards
>>> Andre
>>
>> Is it any faster than OPTLINK?
>
> I had some tries. LLD link is very fast in my applications. It feels even noticeable faster than OPTLINK.
>
> But also I facing some maturity issues.
>
> - While trying to run dub test in combination with dependency d-unit and a module command.d containing an std.datetime import there is always an linker error:
> Native PDB Error: The entry already exists.  The specified module already exists
> I have a reduced test case (dustmite is great!) and will file an issue
>
> - From time to time there is a spurious linker error:
> Error: module `NOLOGO` is in file '\NOLOGO.d' which cannot be read
> I don't know how to reproduce this error but it disappears on next try.
>
> Kind regards
> André

As pointed out by Kinke in issue 19503, dmd ships with an old lld-link version (v5.0.1).
Replacing it with v7.0 (already shipped with recent LDC) solves
the Native PDB Error.

(I have to update the issue https://issues.dlang.org/show_bug.cgi?id=19503)

The spurious NOLOGO problem still occurs on every 3 or 4 try for exactly
the same dmd linker command (generated by dub).

Kind regards
André

On Thursday, 20 December 2018 at 09:24:33 UTC, Andre Pany wrote:
>
> As pointed out by Kinke in issue 19503, dmd ships with an old lld-link version (v5.0.1).
> Replacing it with v7.0 (already shipped with recent LDC) solves
> the Native PDB Error.
>
> (I have to update the issue https://issues.dlang.org/show_bug.cgi?id=19503)
>
> The spurious NOLOGO problem still occurs on every 3 or 4 try for exactly
> the same dmd linker command (generated by dub).
>
> Kind regards
> André

It would be a cool thing to change the default if D_SIMD was defined for -m32mscoff. Was it a OPTLINK problem that D_SIMD isn't there for 32-bit Windows target?