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

Xmake is broken #342966

Open
rennsax opened this issue Sep 19, 2024 · 2 comments
Open

Xmake is broken #342966

rennsax opened this issue Sep 19, 2024 · 2 comments

Comments

@rennsax
Copy link
Member

rennsax commented Sep 19, 2024

Describe the bug

Xmake on Nixpkgs has several issues:

  1. It's non-deterministic. On x86_64 Linux nix run nixpkgs#xmake -- --version:
xmake v2.9.4+20240729, A cross-platform build utility based on Lua
Copyright (C) 2015-present Ruki Wang, tboox.org, xmake.io
                         _
    __  ___ __  __  __ _| | ______
    \ \/ / |  \/  |/ _  | |/ / __ \
     >  <  | \__/ | /_| |   <  ___/
    /_/\_\_|_|  |_|\__ \|_|\_\____|
                         by ruki, xmake.io

    👉  Manual: https://xmake.io/#/getting_started
    🙏  Donate: https://xmake.io/#/sponsor

Here the timestamp is 20240729, which is related to the build date.

  1. It's totally unavailable on aarch64 macOS:
error:
       … while calling the 'derivationStrict' builtin

         at /builtin/derivation.nix:9:12: (source not available)

       … while evaluating derivation 'xmake-2.9.1'
         whose name attribute is located at /nix/store/qkzr5clkyq7j6n43qs5ff73in6c3wacv-source/pkgs/stdenv/generic/make-derivation.nix:333:7

       … while evaluating attribute 'buildInputs' of derivation 'xmake-2.9.1'

         at /nix/store/qkzr5clkyq7j6n43qs5ff73in6c3wacv-source/pkgs/stdenv/generic/make-derivation.nix:380:7:

          379|       depsHostHost                = elemAt (elemAt dependencies 1) 0;
          380|       buildInputs                 = elemAt (elemAt dependencies 1) 1;
             |       ^
          381|       depsTargetTarget            = elemAt (elemAt dependencies 2) 0;

       error: Package ‘tbox-1.7.5’ in /nix/store/qkzr5clkyq7j6n43qs5ff73in6c3wacv-source/pkgs/development/libraries/tbox/default.nix:30 is not available on the requested hostPlatform:
         hostPlatform.config = "aarch64-apple-darwin"
         package.meta.platforms = [
           "aarch64-linux"
           "armv5tel-linux"
           "armv6l-linux"
           "armv7a-linux"
           "armv7l-linux"
           "i686-linux"
           "loongarch64-linux"
           "m68k-linux"
           "microblaze-linux"
           "microblazeel-linux"
           "mips-linux"
           "mips64-linux"
           "mips64el-linux"
           "mipsel-linux"
           "powerpc64-linux"
           "powerpc64le-linux"
           "riscv32-linux"
           "riscv64-linux"
           "s390-linux"
           "s390x-linux"
           "x86_64-linux"
         ]
         package.meta.badPlatforms = [ ]
       , refusing to evaluate.

       a) To temporarily allow packages that are unsupported for this system, you can use an environment variable
          for a single invocation of the nix tools.

            $ export NIXPKGS_ALLOW_UNSUPPORTED_SYSTEM=1

          Note: When using `nix shell`, `nix build`, `nix develop`, etc with a flake,
                then pass `--impure` in order to allow use of environment variables.

       b) For `nixos-rebuild` you can set
         { nixpkgs.config.allowUnsupportedSystem = true; }
       in configuration.nix to override this.

       c) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
         { allowUnsupportedSystem = true; }
       to ~/.config/nixpkgs/config.nix.

buildInputs specified here are not compatible with aarch64 macOS. At least, tbox and xmake-core-sv are unavailable.

  1. It acts abnormally on Linux.
$ nix shell nixpkgs#xmake
$ xmake create -l c -P ./hello
create hello ...
error: cannot open file: xmake.lua, Not access because it is busy
$ cd hello && xmake
error: ./xmake.lua:7: unexpected symbol near '$'
checking for platform ... linux
checking for architecture ... x86_64
error: ./xmake.lua:7: unexpected symbol near '$'

Expected behavior

It should be deterministic and usable. For example,

$ ./result/bin/xmake --version
xmake v2.9.5+19800101, A cross-platform build utility based on Lua
Copyright (C) 2015-present Ruki Wang, tboox.org, xmake.io
                         _
    __  ___ __  __  __ _| | ______
    \ \/ / |  \/  |/ _  | |/ / __ \
     >  <  | \__/ | /_| |   <  ___/
    /_/\_\_|_|  |_|\__ \|_|\_\____|
                         by ruki, xmake.io
    
    👉  Manual: https://xmake.io/#/getting_started
    🙏  Donate: https://xmake.io/#/sponsor

And basic xmake commands should work normally.

Additional context

My simple derivation works properly on macOS. May I create a PR for discussing?

Notify maintainers

@wineee

Metadata

[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"aarch64-darwin"`
 - host os: `Darwin 23.6.0, macOS 14.6.1`
 - multi-user?: `yes`
 - sandbox: `no`
 - version: `nix-env (Nix) 2.18.5`
 - channels(root): `"nixpkgs"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixpkgs`

Add a 👍 reaction to issues you find important.

@Atemu
Copy link
Member

Atemu commented Sep 19, 2024

  1. It's non-deterministic.

This is false. Try and rebuild today and you will see that it's the same date. This is due to the usage of SOURCE_DATE_EPOCH which is set to the youngest mtime of a file in the tarball which corresponds with the release date in most cases.

2. It's totally unavailable on aarch64 macOS:

This is not an issue of the xmake package but the tbox one. Please create a packaging request for that package on Darwin.

error: cannot open file: xmake.lua, Not access because it is busy

That smells like a packaging bug. Could you strace -f -e file xmake ... to figure out where it's trying to openat() that file?

The rest is likely caused by the unusccessful project init.

My simple derivation works properly on macOS. May I create a PR for discussing?

Simple derivation of what exactly?

You are always free to create draft PRs.

@rennsax
Copy link
Member Author

rennsax commented Sep 20, 2024

This is false. Try and rebuild today and you will see that it's the same date. This is due to the usage of SOURCE_DATE_EPOCH which is set to the youngest mtime of a file in the tarball which corresponds with the release date in most cases.

So it's not necessary to build all binary with SOURCE_DATE_EPOCH=315532800 like setup.sh does here? Just need to ensure SOURCE_DATE_EPOCH is the same when realizing each derivation?

That smells like a packaging bug.

You are always free to create draft PRs.

Thanks, let's discuss in the new PR.

@rennsax rennsax mentioned this issue Sep 20, 2024
13 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants