Thread overview
LTS master CI testing
Aug 04, 2017
Johan Engelen
Aug 04, 2017
David Nadlinger
Aug 04, 2017
kinke
Aug 05, 2017
Joakim
Aug 05, 2017
Johan Engelen
Aug 05, 2017
kinke
Aug 05, 2017
Joakim
August 04, 2017
Hi all,
  For LTS master, can we drop the Windows testing?
I think LTS master only makes sense for being able to bootstrap from source. But that's only relevant on Linuxes, right?

I feel it'd make things easier if we just drop as much support as possible, so that we can spend our energy where it matters.

Thanks for input,
  Johan

August 04, 2017
Hi Johan,

In this specific instance (ltsmaster) it would probably be fine to drop support, but generally I'd prefer to place more focus on making things less brittle/easier to test/etc. by fixing the sporadic CI failures, providing default Docker/Vagrant/… dev environments, and so on.

Realistically, the number of different platforms and configurations is only going to increase, and wide platform support is one of the main advantages LDC offers, so it makes sense to reduce the amount of effort required for maintaining them.

Best,
David



On 4 Aug 2017, at 20:02, Johan Engelen via digitalmars-d-ldc wrote:

> Hi all,
>   For LTS master, can we drop the Windows testing?
> I think LTS master only makes sense for being able to bootstrap from source. But that's only relevant on Linuxes, right?
>
> I feel it'd make things easier if we just drop as much support as possible, so that we can spend our energy where it matters.
>
> Thanks for input,
>   Johan
August 04, 2017
On Friday, 4 August 2017 at 19:02:59 UTC, Johan Engelen wrote:
> For LTS master, can we drop the Windows testing?

Sure, it hasn't been working for ages anyway, and installing a D host compiler binary is the most natural thing to do on Windows.
August 05, 2017
On Friday, 4 August 2017 at 19:02:59 UTC, Johan Engelen wrote:
> Hi all,
>   For LTS master, can we drop the Windows testing?
> I think LTS master only makes sense for being able to bootstrap from source. But that's only relevant on Linuxes, right?

Why would the OS matter?  It's so we can port to new platforms by first building the C++-only ltsmaster compiler with the C++ toolchain for the platform.  For example, if someone picks up the new Windows on ARM laptops, coming out in a couple months, they could easily build ltsmaster ldc for it, though the stdlib might require some tweaking.

> I feel it'd make things easier if we just drop as much support as possible, so that we can spend our energy where it matters.

Honestly, I don't care about Windows and don't mind dropping this, just don't see why it'd only matter for linux.
August 05, 2017
On Saturday, 5 August 2017 at 03:06:45 UTC, Joakim wrote:
> On Friday, 4 August 2017 at 19:02:59 UTC, Johan Engelen wrote:
>> Hi all,
>>   For LTS master, can we drop the Windows testing?
>> I think LTS master only makes sense for being able to bootstrap from source. But that's only relevant on Linuxes, right?
>
> Why would the OS matter?

The OS indeed doesn't matter, it's just that I wasn't aware of Windows and MacOSX having a bootstrap problem.

> It's so we can port to new platforms by first building the C++-only ltsmaster compiler with the C++ toolchain for the platform.  For example, if someone picks up the new Windows on ARM laptops, coming out in a couple months, they could easily build ltsmaster ldc for it, though the stdlib might require some tweaking.

Windows on ARM, ok so then we do have a bootstrap problem.

I'll work towards fixing the LLVM download on AppVeyor then.

-Johan

August 05, 2017
On Saturday, 5 August 2017 at 03:06:45 UTC, Joakim wrote:
> Why would the OS matter?

Back at 0.17 times, Windows wasn't fully supported. Rainer's final EH fixes require at least LLVM 3.8 IIRC and probably haven't been ported back. So it's barely usable, and even if the CI build problems are resolved, many tests will fail.

> For example, if someone picks up the new Windows on ARM laptops, coming out in a couple months, they could easily build ltsmaster ldc for it, though the stdlib might require some tweaking.

I thought Windows on ARM was dead, but apparently they're trying it again, this time with a full x86 emulation layer:

"Windows 10 on ARM is completely different. This is the full Windows desktop experience. Microsoft has created a special emulator layer that allows traditional 32-bit desktop applications to run on ARM processors, so everything should “just work”." [1]

If that really works, there's no bootstrapping issue and people can simply install a 32-bit x86 Windows package as host compiler.

[1]: https://www.howtogeek.com/309119/what-is-windows-10-on-arm-and-how-is-it-different-from-windows-rt/
August 05, 2017
On Saturday, 5 August 2017 at 13:03:43 UTC, kinke wrote:
> On Saturday, 5 August 2017 at 03:06:45 UTC, Joakim wrote:
>> Why would the OS matter?
>
> Back at 0.17 times, Windows wasn't fully supported. Rainer's final EH fixes require at least LLVM 3.8 IIRC and probably haven't been ported back. So it's barely usable, and even if the CI build problems are resolved, many tests will fail.

I see, I didn't realize all the Windows fixes for ldc were after that release.

>> For example, if someone picks up the new Windows on ARM laptops, coming out in a couple months, they could easily build ltsmaster ldc for it, though the stdlib might require some tweaking.
>
> I thought Windows on ARM was dead, but apparently they're trying it again, this time with a full x86 emulation layer:
>
> "Windows 10 on ARM is completely different. This is the full Windows desktop experience. Microsoft has created a special emulator layer that allows traditional 32-bit desktop applications to run on ARM processors, so everything should “just work”." [1]
>
> If that really works, there's no bootstrapping issue and people can simply install a 32-bit x86 Windows package as host compiler.
>
> [1]: https://www.howtogeek.com/309119/what-is-windows-10-on-arm-and-how-is-it-different-from-windows-rt/

You're right, this would allow simply running the regular ldc cross-compiler.  Although, Intel has published a blog post threatening lawsuits over x86 patents, which is generally interpreted to be directed at this Microsoft/ARM effort, so it's possible they may remove it in the final release:

https://arstechnica.com/information-technology/2017/06/intel-fires-warning-shots-at-microsoft-claims-x86-emulation-is-a-patent-minefield/