search

alire-project / alire

Command-line tool from the Alire project and supporting library
GNU General Public License v3.0
271 stars 47 forks source link

Adding knowledge of libc-variant to alire #1713

Open AJ-Ianozi opened 4 days ago

AJ-Ianozi commented 4 days ago

This is a continuation of my thoughts on https://github.com/alire-project/alire/issues/792#issuecomment-1758760974

Alire has knowledge of gettingos (linux, windows, macos, freebsd, etc), distribution (though I don't see alpine yet as an option), even host-arch (e.g. x86-64) but while Alire is able to be built with musl (such as on alpine) there's no easy way of detecting that from what I can see.

While most distros use glibc, it looks like quite a few are using musl now. I think it's worth adding a libc-variant (or even just libc) parameter (that defaults to being glibc?) or similar that's passed to alire or detected on build. Maybe then gprbuild's toml will look something like:

[origin."case(os)".linux."case(libc-variant)".glibc."case(host-arch)".x86-64]
url = "https://github.com/alire-project/GNAT-FSF-builds/releases/download/gprbuild-22.0.0-1/gprbuild-x86_64-linux-22.0.0-1.tar.gz"
hashes = ["sha256:24dfc1b54655edd4f85589e7e7dbd0bee24d087f25d5b0f13d3224fe7acf85b8"]

[origin."case(os)".linux."case(libc-variant)".musl."case(host-arch)".x86-64]
url = "https://github.com/alire-project/GNAT-FSF-builds/releases/download/gprbuild-22.0.0-1/gprbuild-x86_64-linux-alpine-22.0.0-1.tar.gz"
hashes = ["sha256:hashgoeshere"]

# Would this help for backwards-compatibility?  We default to glibc.

[origin."case(os)".linux."case(host-arch)".x86-64]
url = "https://github.com/alire-project/GNAT-FSF-builds/releases/download/gprbuild-22.0.0-1/gprbuild-x86_64-linux-22.0.0-1.tar.gz"
hashes = ["sha256:24dfc1b54655edd4f85589e7e7dbd0bee24d087f25d5b0f13d3224fe7acf85b8"]

What do you think? As a bonus, a libc-variant could someday be msvc or something on windows.

mosteo commented 3 days ago

It sounds sensible, although my experience outside of the standard situation is limited. I'd like to hear more from people that have to deal with these solutions.

One thought is: do we risk an exponential growth of combinations? I mean, are there other variables besides libc that we are now also implicitly assuming?

AJ-Ianozi commented 3 days ago

My thoughts is that we probably wouldn't more than this.

My goal with this was to emulate something similar to target triples, which is what I've seen being done in both zig and rust.

It looks like this is a standard that started in GCC but LLVM is using it too.

In this case,, x86_64-windows-gnu is 64-bit MinGW, while x86_64-windows-msvc is 64-bit MSVC; some other examples are x86_64-linux-musl (64-bit linux using musl), aarch64-linux-gnu (arm linux using glibc), etc (I'm pulling from Zig's list linked above).

It is possible for some platforms to use 4 entries in their "triple", Rust does this, but it almost always says either "-pc-" or "-unkown-" so it didn't seem relevant for us.

mosteo commented 2 days ago

I see, thanks for the further info. Next question, what would be a reliable way of detecting which libc a system uses? Preferably without introducing new dependencies.