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

Lock file is cleared when configuring on Windows #5532

Closed
AidanSun05 opened this issue Aug 28, 2024 · 5 comments
Closed

Lock file is cleared when configuring on Windows #5532

AidanSun05 opened this issue Aug 28, 2024 · 5 comments
Labels
Milestone

Comments

@AidanSun05
Copy link

Xmake Version

xmake v2.9.4+HEAD.e85b001f1

Operating System Version and Architecture

Windows 11 Pro 23H2 x64

Describe Bug

On Windows, when configuring with xmake f ... in a project that has an xmake-requires.lock file, the windows|x64 entry in the file is cleared. This does not happen on other operating systems such as macOS 14.6.

After running xmake f -p windows -a x64 -m debug -c, xmake-requires.lock is:

{
    __meta__ = {
        version = "1.0"
    },
    ["windows|x64"] = { }
}

Expected Behavior

The contents of the lock file are kept and xmake installs dependencies from the lock file.

Project Configuration

xmake.lua:

add_rules("mode.debug", "mode.release")
set_policy("package.requires_lock", true)

add_requires("utfcpp")

target("test")
    add_packages("utfcpp")
    set_kind("binary")
    add_files("src/*.cpp")

xmake-requires.lock:

{
    __meta__ = {
        version = "1.0"
    },
    ["windows|x64"] = {
        ["cmake#31fecfc4"] = {
            repo = {
                branch = "master",
                commit = "2565721b35dce693aa479d50326dae9715faa578",
                url = "https://gitlab.com/tboox/xmake-repo.git"
            },
            version = "3.29.2"
        },
        ["utfcpp#31fecfc4"] = {
            repo = {
                branch = "master",
                commit = "52e84d5aa56cf9e3ce66f167fe82df586461c0a9",
                url = "https://gitlab.com/tboox/xmake-repo.git"
            },
            version = "v4.0.5"
        }
    }
}

src/main.cpp:

#include <utf8.h>

int main() {}

Additional Information and Error Logs

Output of xmake f -p windows -a x64 -m debug -c -vD:

checking for cl.exe ... C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.41.34120\bin\HostX64\x64\cl.exe
checking for Microsoft Visual Studio (x64) version ... 2022
checking for Microsoft C/C++ Compiler (x64) version ... 19.41.34120
checkinfo: cannot runv(zig.exe version), No such file or directory
checking for zig ... no
checkinfo: cannot runv(zig.exe version), No such file or directory
checking for zig ... no
checkinfo: cannot runv(nim.exe --version), No such file or directory
checking for nim ... no
checkinfo: cannot runv(nim.exe --version), No such file or directory
checking for nim ... no
checkinfo: cannot runv(unzip.exe -v), No such file or directory
checking for unzip ... no
checking for 7z ... C:\Program Files\xmake\winenv\bin\7z
checking for git ... ok
checkinfo: cannot runv(gzip.exe --version), No such file or directory
checking for gzip ... no
git rev-parse HEAD
lock package(utfcpp) in C:\Users\Aidan\Code\test\.xmake\windows\x64\repositories\d37d6f9715bc404d9cc2a582947d2c1f.lock\packages\u\utfcpp from repository(https://gitlab.com/tboox/xmake-repo.git)/52e84d5aa56cf9e3ce66f167fe82df586461c0a9
git rev-parse HEAD
git rev-parse HEAD
lock package(cmake) in C:\Users\Aidan\Code\test\.xmake\windows\x64\repositories\c1744cf66b2a4c3081f68c9ef1e74c96.lock\packages\c\cmake from repository(https://gitlab.com/tboox/xmake-repo.git)/2565721b35dce693aa479d50326dae9715faa578
git rev-parse HEAD
checking for cmake ... no
checking for cmake ... no
checking for cmake ... no
finding utfcpp from xmake ..
checking for xmake::utfcpp ... no
finding utfcpp from vcpkg ..
finding utfcpp from conan ..
finding utfcpp from pkgconfig ..
checkinfo: cannot runv(pkg-config.exe --version), No such file or directory
checking for pkg-config ... no
checkinfo: cannot runv(pkgconf.exe --version), No such file or directory
checking for pkgconf ... no
finding utfcpp from system ..
checking for cl.exe ... C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.41.34120\bin\HostX64\x64\cl.exe
checking for the c compiler (cc) ... cl.exe
> "C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.41.34120\\bin\\HostX64\\x64\\cl.exe" -c -nologo -FoC:\Users\Aidan\AppData\Local\Temp\.xmake\240828\_3E6EB5232A294B20889FC37733B91B70.o C:\Users\Aidan\AppData\Local\Temp\.xmake\240828\_775FB00633BC4F66BF87D39CCDE5CF30.c
checking for cl.exe ... C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.41.34120\bin\HostX64\x64\cl.exe
checking for the c++ compiler (cxx) ... cl.exe
checking for link.exe ... C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.41.34120\bin\HostX64\x64\link.exe
checking for the linker (ld) ... link.exe
> "C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.41.34120\\bin\\HostX64\\x64\\link.exe" -nologo -dynamicbase -nxcompat -machine:x64 utfcpp.lib -out:C:\Users\Aidan\AppData\Local\Temp\.xmake\240828\_3E6EB5232A294B20889FC37733B91B70.b C:\Users\Aidan\AppData\Local\Temp\.xmake\240828\_3E6EB5232A294B20889FC37733B91B70.o
> checking for c links(utfcpp)
> checking for c snippet(find_package/utfcpp)
checkinfo: ...gramdir\core\sandbox\modules\import\core\tool\linker.lua:75: @programdir\modules\core\tools\link.lua:175: LINK : fatal error LNK1181: cannot open input file 'utfcpp.lib'

stack traceback:
    [C]: in function 'error'
    [@programdir\core\base\os.lua:973]:
    [@programdir\modules\core\tools\link.lua:175]: in function 'catch'
    [@programdir\core\sandbox\modules\try.lua:123]: in function 'try'
    [@programdir\modules\core\tools\link.lua:150]:
    [C]: in function 'xpcall'
    [@programdir\core\base\utils.lua:241]:
    [@programdir\core\tool\linker.lua:222]: in function 'link'
    [...gramdir\core\sandbox\modules\import\core\tool\linker.lua:73]: in function 'link'
    [@programdir\modules\lib\detect\check_cxsnippets.lua:249]:
    [C]: in function 'xpcall'
    [@programdir\core\base\utils.lua:241]: in function 'trycall'
    [@programdir\core\sandbox\modules\try.lua:117]: in function 'try'
    [@programdir\modules\lib\detect\check_cxsnippets.lua:236]:
    [@programdir\modules\package\manager\system\find_package.lua:73]:
    [@programdir\modules\package\manager\find_package.lua:84]: in function '_find_package_with_builtin_rule'
    [@programdir\modules\package\manager\find_package.lua:130]: in function '_find_package'
    [@programdir\modules\package\manager\find_package.lua:194]:
    [@programdir\modules\lib\detect\find_package.lua:109]:
    [@programdir\core\package\package.lua:1856]: in function '_fetch_library'
    [@programdir\core\package\package.lua:2026]: in function 'fetch'
    [...modules\private\action\require\impl\install_packages.lua:340]: in function 'jobfunc'
    [@programdir\modules\async\runjobs.lua:241]:
    [C]: in function 'xpcall'
    [@programdir\core\base\utils.lua:241]: in function 'trycall'
    [@programdir\core\sandbox\modules\try.lua:117]: in function 'try'
    [@programdir\modules\async\runjobs.lua:223]: in function 'cotask'
    [@programdir\core\base\scheduler.lua:406]:

checking for utfcpp ... no
note: install or modify (m) these packages (pass -y to skip confirm)?
in d37d6f9715bc404d9cc2a582947d2c1f.lock:
  -> utfcpp v4.0.5
please input: y (y/n/m)
@AidanSun05 AidanSun05 added the bug label Aug 28, 2024
@waruqi
Copy link
Member

waruqi commented Aug 29, 2024

But it works for me.

PS C:\Users\wangrunqing\Downloads\test91> xmake
checking for Microsoft Visual Studio (x64) version ... 2022
checking for Microsoft C/C++ Compiler (x64) version ... 19.41.33923
updating repositories .. ok
note: install or modify (m) these packages (pass -y to skip confirm)?
in xmake-repo:
  -> utfcpp v4.0.5
please input: y (y/n/m)

  => download https://github.com/nemtrif/utfcpp/archive/refs/tags/v4.0.5.tar.gz .. ok
  => install utfcpp v4.0.5 .. ok
[ 50%]: compiling.release src\main.cpp
[ 75%]: linking.release test.exe
[100%]: build ok, spent 0.906s
PS C:\Users\wangrunqing\Downloads\test91> xmake f -p windows -a x64 -m debug -c
checking for Microsoft Visual Studio (x64) version ... 2022
checking for Microsoft C/C++ Compiler (x64) version ... 19.41.33923
PS C:\Users\wangrunqing\Downloads\test91> xmake f -p windows -a x64 -m debug -c
checking for Microsoft Visual Studio (x64) version ... 2022
checking for Microsoft C/C++ Compiler (x64) version ... 19.41.33923
PS C:\Users\wangrunqing\Downloads\test91> xmake l io.readfile xmake-requires.lock
"{
    __meta__ = {
        version = "1.0"
    },
    ["windows|x64"] = {
        ["cmake#31fecfc4"] = {
            repo = {
                branch = "master",
                commit = "e8e9c3380b4aec761f781927c2434b75db50aa90",
                url = "https://gitee.com/tboox/xmake-repo.git"
            },
            version = "3.29.0-rc1"
        },
        ["utfcpp#31fecfc4"] = {
            repo = {
                branch = "master",
                commit = "e8e9c3380b4aec761f781927c2434b75db50aa90",
                url = "https://gitee.com/tboox/xmake-repo.git"
            },
            version = "v4.0.5"
        }
    }
}"

@waruqi
Copy link
Member

waruqi commented Aug 29, 2024

Are you using the dev version now? I remember just recently fixing a require lock bug that could cause you to reinstall locked packages. You need to reinstall the locked packages.

#5465

@AidanSun05
Copy link
Author

AidanSun05 commented Aug 29, 2024

I tried the latest dev version (v2.9.4+dev.2a2ee54fe) and this is what I noticed:

  • When the configure command is paused on confirming to install packages ("please input: y (y/n/m)") the lock file is cleared.
  • When the packages are successfully installed and the configure command finishes, the lock file is back to how it originally was.

Interestingly, I could not reproduce this on macOS even with the same dev version: the lock file (with windows|x64 replaced with macosx|arm64) is never cleared when the configure command runs (xmake f -p macosx -a arm64 -m debug -c). Is this varying behavior intended?

waruqi added a commit that referenced this issue Aug 29, 2024
@waruqi
Copy link
Member

waruqi commented Aug 29, 2024

try this patch. #5539

@waruqi waruqi added this to the v2.9.5 milestone Aug 29, 2024
waruqi added a commit that referenced this issue Aug 29, 2024
@AidanSun05
Copy link
Author

Thanks, the lock file is now retained throughout the entire process of configuring and installing packages. This is consistent with the expected behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants