-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider dropping i386 builds of the snap package #52
Comments
We're only talking about a small subset of the entire testsuite, namely, 1) lit-tests, 2) druntime standalone tests and 3) ldc2-unittest, which aren't CI-tested for 32-bit x86 Posix (but there's a 32-bit Windows/MSVC CI build and release package). The 32-bit dmd-testsuite and library unittest variants are run as part of the multilib CI jobs. As to whether a 32-bit snap package is (still) worth it, I have no idea, do you have some download stats?
I'd say you can expect official LDC packages for AArch64 Debian-based Linux to be available as soon as it's fully supported; I don't know whether they could be used directly for the snap packages. |
I would expect that to be straightforward to support. |
Not AFAIK on an architecture-by-architecture basis. :-( Question: why does LDC not actually have an i386 build in its CI? And would you be open to one? I ask because I am considering whether it might be worth trying to rework snap-package generation on the basis of CircleCI-generated binaries (to avoid duplication of effort and divergence of functionality). |
I personally don't see much value in a 32-bit Linux package. Wrt. CI testing, it's both simpler and more efficient if the 32-bit tests are run as part of the multilib jobs (well, once ldc-developers/ldc#2727 is resolved), which currently cover Ubuntu 14.04 + 18.04 and macOS. |
Yes, I suppose that's reasonable -- the compiler (whether built for 32 or 64 bit hosts) should produce the same output for both 64 and 32 bit targets. So passing the 32-bit tests in a multilib job should be fine. |
Currently the main LDC project seems to produce builds and packages only for 64-bit systems, while including LLVM targets for other systems. In the past this has mean that problems that only show up with 32-bit builds have hit the snap package while remaining undetected upstream. It also constrains the design of the snap package: for example, if only amd64 was supported as the platform on which the snap package was to be installed, it would likely be possible to use the binaries already built by the main LDC CI system.
On the other hand, limiting the snap package in this way might make it hard (for example) to build snap packages for other systems like arm64 (which may not be possible now, but which might be desirable in future).
I'm interested in what other people think of the issue here. In some ways it seems that it might be best to only create snap packages for platforms directly supported by LDC upstream, and to extend the range of such platforms as they expand in LDC's own CI.
The text was updated successfully, but these errors were encountered: