Skip to content
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

Open
WebDrake opened this issue Jun 3, 2018 · 5 comments
Open

Consider dropping i386 builds of the snap package #52

WebDrake opened this issue Jun 3, 2018 · 5 comments
Labels

Comments

@WebDrake
Copy link
Contributor

WebDrake commented Jun 3, 2018

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.

@kinke
Copy link
Member

kinke commented Jun 6, 2018

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.

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.
Adding a 32-bit lit-tests run for multilib builds would be especially helpful; I'll create an issue.

As to whether a 32-bit snap package is (still) worth it, I have no idea, do you have some download stats?

limiting the snap package in this way might make it hard (for example) to build snap packages for other systems like arm64

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.

@WebDrake
Copy link
Contributor Author

WebDrake commented Jun 7, 2018

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.

@WebDrake
Copy link
Contributor Author

WebDrake commented Jun 7, 2018

As to whether a 32-bit snap package is (still) worth it, I have no idea, do you have some download stats?

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

@kinke
Copy link
Member

kinke commented Jun 7, 2018

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.

@WebDrake
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants