search

fyne-io / fyne-cross-images

Repository for managing fyne-cross images
BSD 3-Clause "New" or "Revised" License
5 stars 9 forks source link

Move image base to Alpine #52

Open Jacalz opened 4 months ago

Jacalz commented 4 months ago

As a much further step than https://github.com/fyne-io/fyne-cross-images/issues/49, we should look at potentially switching to Alpine Linux for the base image (if possible).

Alpine images are tiny in size and should likely allow us to shave many megabytes from our images and thus make downloads smaller. Smaller downloads will of course be helpful for a lot on people; especially for downloads on metered connections and gives a smaller installed footprint.

Bluebugs commented 4 months ago

I don't think that is possible or a good idea. Alpine rely on musl for libc which is not what most distribution use. The generated binary might be incompatible and we still need to distribute gnu libc to do the linking, so I don't expect much gain once you get all working.

Alpine is great for container in cluster that require a lot of dependencies, but it isn't a great solution to do compilation work.

Jacalz commented 4 months ago

I am aware of it using musl and the downside that you mention but I figured that it wouldn't be a problem for us given that Zig should contain all of the glibc bits that we need for the compiles?

Bluebugs commented 4 months ago

Except it only has the glibc bits, none of the other dependencies are there (X, Wayland, glfw, ...) and we would need to download the debian package anyway for those. I don't think it is worse the time, effort and maintenance burden to follow such a route.

Jacalz commented 4 months ago

But header files are header files and those packages are there and installable no matter how you look at it; there is even Alpine Linux setup documentation at https://docs.fyne.io/started/. Why would that not work? I don't see any reason for why Debian packages would need to be installed on top.

Bluebugs commented 4 months ago

Except header in C can have macro that depends on the C library you are using at the time of compilation and can lead to incompatible code being generated.

Jacalz commented 4 months ago

Yes but are those macros really set when the development package is created? Zig has support for switching between compiling with glibc and musl (which I've used on glibc to compile binaries with musl), surely it would set those macros correctly at build time?