Open vspefs opened 4 weeks ago
you can open a pr to add add_extsources
or on_fetch to improve to find system library for glfw package.
e.g. add_extsources("pkgconfig::glfw3")
and you can refer other packages in xmake-repo
It work for me= =
add_requires("glfw", {system = true})
$ xmake f -c -y -vD
checking for platform ... mingw
checking for architecture ... x86_64
checking for mingw directory ... C:/Users/star/scoop/apps/msys2/2024-07-27/mingw64
checkinfo: cannot runv(unzip -v), No such file or directory
checking for unzip ... no
checking for 7z ... ok
checking for git ... ok
checking for gzip ... ok
checking for tar ... ok
git rev-parse HEAD
checking for cmake ... no
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
checking for cmake ... no
checking for cmake ... no
checking for cmake ... ok
checking for xmake-repo::opengl ... opengl
checking for pacman ... ok
checkinfo: cannot runv(emerge --version), No such file or directory
checking for emerge ... no
finding glfw from vcpkg ..
finding glfw from conan ..
finding glfw from pkgconfig ..
checking for pkg-config ... ok
finding glfw from pacman ..
checking for x86_64-w64-mingw32-gcc ... C:\Users\star\scoop\apps\msys2\2024-07-27\mingw64\bin\x86_64-w64-mingw32-gcc
checking for the c compiler (cc) ... x86_64-w64-mingw32-gcc
> C:\Users\star\scoop\apps\msys2\2024-07-27\mingw64\bin\x86_64-w64-mingw32-gcc -c -m64 -o C:\Users\star\scoop\apps\msys2\2024-07-27\tmp\.xmake\240815\_F6A3B3A047DD416088DF1851D05151E0.o C:\Users\star\scoop\apps\msys2\2024-07-27\tmp\.xmake\240815\_775FB00633BC4F66BF87D39CCDE5CF30.c
checking for C:\Users\star\scoop\apps\msys2\2024-07-27\mingw64\bin\x86_64-w64-mingw32-gcc ... ok
checking for flags (-fdiagnostics-color=always) ... ok
> x86_64-w64-mingw32-gcc "-fdiagnostics-color=always" "-m64"
checking for x86_64-w64-mingw32-g++ ... C:\Users\star\scoop\apps\msys2\2024-07-27\mingw64\bin\x86_64-w64-mingw32-g++
checking for the linker (ld) ... x86_64-w64-mingw32-g++
> C:\Users\star\scoop\apps\msys2\2024-07-27\mingw64\bin\x86_64-w64-mingw32-g++ -o C:\Users\star\scoop\apps\msys2\2024-07-27\tmp\.xmake\240815\_F6A3B3A047DD416088DF1851D05151E0.b C:\Users\star\scoop\apps\msys2\2024-07-27\tmp\.xmake\240815\_F6A3B3A047DD416088DF1851D05151E0.o -m64 -lglfw3
> checking for c links(glfw3)
> checking for c snippet(find_package/glfw3)
checking for cygpath ... ok
checking for glfw ... pacman::glfw 3.4.0
Xmake Version
2.9.4
Operating System Version and Architecture
Windows 11 21H2 Home. Using msys2, on clang64 environment
Describe Bug
A package holds multiple alias-es, like X, Y and Z. You can find the package using all the alias-es, but the target file to be linked to is named after one of them, for example, Y. When xmake successfully finds the system package and goes on to test if the compiler could actually link against the library, it tests only by adding the compiler flag "-lX", in which X is the package name we specify in our xmake.lua, instead of the real name we should use, Y.
Expected Behavior
Whichever package name we specify in xmake.lua, xmake could use the right name for the target file while testing if the library links.
Project Configuration
Additional Information and Error Logs
using
add_requires("glfw3")
using
add_requires("glfw")
As you see, it fails to locate the system package.