Create docker files to build LLVM and C3C on more Linux distros

[lerno]

There is a problem with Fedora #779 and also with Arch Linux #759. This is usually a problem with the LLVM distribution. It is very popular to make half-working LLVM distros, like excluding some targets, removing some features, not providing static libraries etc. The official Ubuntu and Debian builds have had problems over and over again.

There is a similar problem with Windows LLVM distros. They're basically often messed up. But we don't need to worry about this anymore since the project has its own version of LLVM built from sources.

This is great, but we should do the same for Linux, providing LLVM versions for a wide number of distros using CI. However, Github CI only provides Ubuntu, so there is a need to do all of this through docker.

We should at least make sure that Fedora, Arch, Gentoo and OpenSuse have binaries and LLVM libraries.

[Its-Kenta]

might be old log, but c3 installs fine on Arch now.
Just tested with AUR helper and it installed without a problem.

[lerno]

That's good to hear. Now the next thing is just to get docker images for the previously mentioned distros and make sure it works for those as well.

[lerno]

I'd love to have docker CI for netbsd openbsd and freebsd as well, so those could be checked. Not to mention aarch64 variants of mac/win/linux

[Its-Kenta]

I will be checking aarch64 for Mac probably next week and probably dockers for linux distros if I manage to have some time

[lerno]

That would be awesome.

[DeanHnter]

I did a test for some linux distros and have some working results but it requires some larger changes for the following reasons.

1. One of the issues with the current docker-build script is that the package names differ between distros so the current docker build script becomes more complex particularly for the DEPS variable, as you have to support all package name variations across all targeted distros so I found it easier to just define in each distros dockerfile which dependency that distro has rather than injecting the dependency from the build script into the dockerfile.

2. It is possible a docker build actually is successful today but fails tomorrow, I am finding this to be the case with the current dockerfile for ubuntu which used to work for me but currently fails after cleaning my cache due to the apt-repository being an external dependency and older releases not being supported anymore resulting in the error for example "kinetic-security Release' does not have a Release file.".

"The repositories for older releases that are not supported (like 11.04, 11.10 and 13.04) get moved to an archive server. There are repositories available at http://old-releases.ubuntu.com/." 22.10 went EOL in april.

Effectively this means that if the dockerfiles expire you must go back and modify the sources.list for ubuntu and its unclear how many other distros would have a similar issue.

3. Some distros dont ship clang easily from a repository so some distros require you to build clang from source, which can take a long time to run frequently, runnning once and storing the result would increase the overall build speed.

I would suggest splitting the configuration into two distinct github action steps:

1. Create a build machine image from a dockerfile or packer with docker/iso.
2. Provision the builder using the previously configured image with the C3 Sources to compile mounted inside and build the required artefacts.

This should make it easier to guarantee reproducible legacy builds. The negatives would be maintaining sources of the build machines by version and the requirement of having an external repository to store the images for example dockerhub or vagrant-boxes.

Probably it would be useful if there is a C3 account on one of these static image hosting sites for pre-built images and a common secret pattern integrated into the github actions so it would be possibly to complete such a task.

[lerno]

That sounds like you know how to implement it but you're lacking some help for some of the moving parts @DeanHnter ?

[SMFloris]

@DeanHnter , for this case specifically like apt-repository being an external dependency and versions you rely on potentially dissapear:

I recommend Docker should not be used as a distribution mechanism since it is also based on distros that have lot of moving parts.

@lerno , I do allot of docker stuff in my day to day job and I am willing to help out. What is it that we are trying to achieve here? Having a c3c compiler single binary that would work on any distro?

[lerno]

@SMFloris no, what I want is for the CI script to generate binaries for as many distros as possible, because currently the "linux" binaries are Ubuntu and Debian. There is also a reoccurring problem with LLVM sometimes not being correctly built, so ideally there is a CI script that also builds some working version of LLVM to use for building these Linux binaries.

[SMFloris]

@lerno , I took a closer look on the issues mentioned #779 and #759

I think I see what you mean; distros either have llvm/lld statically or dynamically or in all sorts of locations or split across many packages. I guess it's not the worst ideea to have a custom working version on LLVM to use in building the binaries.

I would normally argue against this kind of approach. This repo is the 'upstream' and it falls on the shoulders of the maintainers of the packages to make it work inside their own distros and advocate for a correctly build llvm. The maintainers should be the ones making c3 work on their distros.

Case in point, I have recently started doing Advent of Code in c3. I use NixOs, I made it work for my distro and updated the package to the latest release, made a PR to nixpkgs and the lot. Yeah sure, LLD libs were in a weird location; But they were there and I was able to make it work. Of course, this being a 'new' language, more easily installable ways on a distro means potentially more people testing it; also adoption might be slow so maybe we'd like just shipping the whole shebang in order to help early adopters out and not rely on maintainers.

About shipping the whole thing so it just works for the end user: I still don't see why we should compile our own llvm each time for each distro. It just seems like such a drag with so many moving parts in distros (and in their politics!).
LLVM actually has a release page: https://releases.llvm.org/download.html so if we can make c3 work with each released version we can just ship everything as a whole tar.gz alongside a working LLVM.

So basically, instead of going after each distro one at a time; we do a release for the whole architecture with everything embedded in it (sort of like Go did and still does). This would give a way for precious early adopters to start tinkering easily (just untar and run) and give time to distro and their package maintainers to fix their stuff.

[lerno]

The problem is that several times, the prebuilt binaries from LLVM have been broken. The most common break is for the cmake scripts to be incorrect and not work, but other things break as well. In addition, the x86 Linux binaries only work on Debian.

So I'm unsure what you're suggesting for Linux here? I'd like to compile C3 as a CI and offer the resulting statically linked binary without any need to compile it from source. If people want to do that then it's fairly straightforward.

Edit: Then there is the question of doing CI for these other installs of Linux, but also FreeBSD, NetBSD and OpenBSD.

[ellipse12]

Personally I would think that forking llvm and building it in each docker image would be the easiest way to support multiple architectures/systems, or you could build it once for linux/windows and just mount the folder that contains that build. im not sure exactly what you mean by each distro though, do you want to automatically package it for each distro, or are there hard-coded paths in the compiler? Im fairly new to docker/ llvm so I may be confused.