regression in lit install

[Bilal2453]

As of #333 a regression that breaks native binary installs was introduced, due to the used replacement luv.os_uname().machine, which is NOT equivalent to ffi.arch.

Meaning, packages that used to have this in its package.lua:

  files = {
    "$OS-$ARCH/*",
    "**.lua",
  }

and had a folder with the name Windows-x64 are now broken.

luv.os_uname().machine --> x86_64.
vs
ffi.arch --> x64.

Lit now expects the folder to be called Windows-x86_64 which is a breaking change.

Acceptable $ARCH values are one of the following values, and only one of them: x86, x64, arm, arm64be, arm64, ppc64le, ppc64, ppc, mips32r6el, mipsel, mips64r6el, mips64el, mips32r6, mips, mips64r6, mips64,
I think it is easier to just reintroduce the ffi API.

[squeek502]

Could also have a translation table to go from uname -> ffi name

[Bilal2453]

Seems like, at least libuv's implementation on Windows, is limited to the following architecture names:

x86_64
ia64
i386
i686
mips
alpha
powerpc
sh
arm
unknown

Sounds like it is impossible to fully make it backwards compatible with the ffi.arch behavior?

Edit: We could query all packages on lit.luvit.io for the used architectures, ensuring those are compatible using a translation table, and screwing up the rest with whatever uname spits. That does not ensure other Lit servers won't break though.
But I don't see a solution beyond that sadly, at least not without deploying very hacky solutions (like running shell scripts).