actboy168 / bee.lua

Lua runtime and toolset
MIT License
158 stars 30 forks source link

MacOS filesystem test (filesystem.test_appdata_path) fails on MacPorts #21

Closed judaew closed 2 years ago

judaew commented 2 years ago

Test error during build. At compile time, I set the HOME variable to the following path:

/opt/local/var/macports/build/.../lua-language-server/work/.home

I also tried to create a Library/Caches directory inside HOME, but it was also unsuccessful.

If I try to manually compile luamake, I get the following error:

$ sudo -u macports HOME="/opt/local/var/macports/sources/.../work/lua-language-server-2.4.2/.home" ninja -C 3rd/luamake -f compile/ninja/macos.ninja

ninja: Entering directory `3rd/luamake'
[0/1] build/macos/bin/luamake 3rd/bee.lua/test/test.lua
OS:         macOS
Arch:       x86_64
Compiler:   Clang 13.0.0
CRT:        libc++ 12000
DEBUG:      false
............................................F................................................
Failed tests:
-------------
1) filesystem.test_appdata_path
3rd/bee.lua/test/test_filesystem.lua:38: expected: /opt/local/var/macports/sources/github.com/judaew/macports-ports/lua/lua-language-server/work/lua-language-server-2.4.2/.home/Library/Caches, actual: /opt/local/var/macports/home/Library/Caches
stack traceback:
    3rd/bee.lua/test/test_filesystem.lua:38: in upvalue 'assertPathEquals'
    3rd/bee.lua/test/test_filesystem.lua:786: in upvalue 'filesystem.test_appdata_path'

Ran 93 tests in 0.414 seconds, 92 successes, 1 failures
FAILED: build/macos/_/test 
build/macos/bin/luamake 3rd/bee.lua/test/test.lua
ninja: build stopped: subcommand failed.

https://github.com/actboy168/bee.lua/blob/e2a8a4f16aafb978ecd3661871ca093bebe649ff/test/test_filesystem.lua#L780-L788

actboy168 commented 2 years ago

You should not modify $HOME.

judaew commented 2 years ago

MacPorts creates a working directory for building a port, which contains the project directory and a temporary .home. I think the macports user from whom the build is taking place does not have real HOME directory. The .home is used for projects that need HOME (for example, for projects that use cargo).

actboy168 commented 2 years ago

I don't know why macports does such a thing during the build phase, and whether it does the same hook during the application run phase. The test is to run the application as expected. If the test environment is inconsistent with the running environment, the meaning of the test is lost. So I still think you should not change $HOME, or you should make sure that the test passes.

judaew commented 2 years ago

I asked about this behavior. MacPorts clears almost all environment variables during port construction. Therefore, if I do not set a variable, then it will not exist.

Thank you for helping me figure out what this test is responsible for. The application will not run from the macports user (which doesn't have itself real $HOME directory). In this case, I will skip this test by adding a patch.

carlocab commented 2 years ago

Changing HOME to a temporary directory is a common strategy used by package managers to ensure that a user's HOME is not polluted by build products when building software, and to help ensure that binaries don't reference specific details of the machine used to build (in order to make binaries redistributable).

Is it possible to add a build option to skip this particular test during the build? It would help simplify packaging of bee.lua (or other software that use it) a lot.

See, for example, Homebrew/homebrew-core#90453.

actboy168 commented 2 years ago

@carlocab MacPorts only hooked HOME, but did not hook NSCachesDirectory. For MacPorts, something unexpected will happen. But it just lost a correct test for bee.lua.

I can remove this test, it is not an important thing.