Closed mcclure closed 4 months ago
There is the common and annoying case that happens on MSVC toolchains only which produces "Debug" and "Release" sub-directories to put executables into it, and this case confuses other part of code that expects their default placement. I could try to work around on this. You are lucky, because you wrote when I am on my computer right now, so, I'll make the workaround very soon.
Thanks very much. By the way, letting the build fail, then running
copy C:\Users\Andi\work\g\lovr\build-apk\luajit\src\minilua\Debug\minilua.exe C:\Users\Andi\work\g\lovr\build-apk\luajit\src\minilua\minilua.exe
then running the build again, letting it fail on buildvm, then running
copy C:\Users\Andi\work\g\lovr\build-apk\luajit\src\buildvm\Debug\buildvm.exe C:\Users\Andi\work\g\lovr\build-apk\luajit\src\buildvm\buildvm.exe
then running the build again produces an apparently working LuaJIT. So I think I am at the moment unblocked. But obviously this is suboptimal and it would be good to fix it for the next person anyway.
Just now I sent the thing, please try to build it from the scratch, will it work or not?
Hello, thanks much. I pulled the luajit used for this build up to b4369853fcf2d2a9463 and recompiled with the same steps. Unfortunately it fails in the same place with what seems to be the same error.
C:\Users\Andi\work\g\lovr\deps\luajit\src\host\minilua.c(7633,1): warning C4996: 'sprintf': This function or variable may be unsafe. Consider using sprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details. [C:\Users\Andi\work\g\lovr\build-apk\luajit\src\minilua\minilua.vcxproj]
minilua.vcxproj -> C:\Users\Andi\work\g\lovr\build-apk\luajit\src\minilua\Debug\minilua.exe
Building Custom Rule C:/Users/Andi/work/g/lovr/deps/luajit/src/host/cmake/minilua/CMakeLists.txt
[208/457] Generating buildvm_arch.h
FAILED: luajit/src/buildvm_arch.h C:/Users/Andi/work/g/lovr/build-apk/luajit/src/buildvm_arch.h
cmd.exe /C "cd /D C:\Users\Andi\work\g\lovr\build-apk\luajit\src && C:\Users\Andi\work\g\lovr\build-apk\luajit\src\minilua\minilua.exe C:/Users/Andi/work/g/lovr/deps/luajit/src/../dynasm/dynasm.lua -D FPU -D HFABI -D ENDIAN_LE -D P64 -D FFI -D JIT -D DUALNUM -D VER= -o C:/Users/Andi/work/g/lovr/build-apk/luajit/src/buildvm_arch.h C:/Users/Andi/work/g/lovr/deps/luajit/src/vm_arm64.dasc"
'C:\Users\Andi\work\g\lovr\build-apk\luajit\src\minilua\minilua.exe' is not recognized as an internal or external command,
operable program or batch file.
[213/457] Building CXX object glslang/glslang/CMakeFiles/MachineIndependent.dir/MachineIndependent/linkValidate.cpp.o
ninja: build stopped: subcommand failed.
Note: To be clear this was a clean build, I totally deleted the previous work tree.
Looking at 5c4ccfa9c9f86f4
I am not sure I understand these changes, but:
Would this have effect on normal Windows builds? I think changing normal, non-Android-cross-compile Windows builds might not be a good idea. If the Debug/ is chopped off on normal (pure Windows) builds this might have unpredictable effects if two configurations are built from the same work tree.
It might be better to look for the exe in a different place if it somehow detects it's about to re-invoke a Windows build (I don't know if that's possible) rather than try to change where it's saved.
Thanks again though.
Usually, the debug/release is defined by the CMAKE_BUILD_TYPE=
variable, and these sub-directoreis aren't so useful, and they kills the cross-platform unification of the directory tree. And so, for debug and for release the separated build tree is required. And, this mess happens on MSVC toolchains only, on MinGW-based toolchains it works just fine.
Anyway, could you show me the content of the "src/host/cmake/buildvm/" and "src/host/cmake/minilua/" inside the build directory?
Contents of src/ after first failure (minilua.exe not found):
Contents of src/ after manual copy of minilua.exe and second failure (buildvm.exe not found)
Contents of src/ after manual copy of buildvm.exe and successful build:
EDIT: This is with b4369853fcf2
Damn... that means my workaround didn't worked. It's supposed it will force these executables being placed at the build-apk/luajit/src/minilua/
, not at build-apk/luajit/src/minilua/Debug
.
I'll try something other soon.
Yes, the exes were still in the Debug folder.
Just now I made another workaround, it should work now. I'll try out the thing on another machine to ensure it works fine.
Okay, locally at me, it puts binaries at the right place now, no longer into Debug/Release sub-directories.
I just confirmed that this is working now in lovr.
Then, I can close this. Thanks for the confirmation!
Hello, I use your distribution of LuaJIT as part of the https://github.com/bjornbytes/lovr game development library, which includes your LuaJIT as a a CMake
add_subdirectory
. The CMake file in your distribution is extremely useful and works much better than the bodged one we used before. I have successfully used it to build on MacOS, build on Windows, and to cross-compile an Android version from a MacOS build machine.Today I tried to use it to cross-compile an Android version from a Windows build machine. But it failed, and it failed because of a very small, fiddly configuration issue. The final lines of the build were:
Looking carefully, what went wrong is clear: It builds the helper
C:\Users\Andi\work\g\lovr\build-apk\luajit\src\minilua\Debug\minilua.exe
. Then it attempts to executeC:\Users\Andi\work\g\lovr\build-apk\luajit\src\minilua\minilua.exe
. Notice the Debug\ directory. The MSVC generator for cmake likes to put exes inside a Debug\ or Release\ subdirectory. However the .exe is then being invoked by (I think) the Ninja generator, which does not include that Debug/Release subdirectory when constructing the path it attempts to run minilua.exe from.Is there some way to fix this?
Here is my command line build invocation, unfortunately in addition to being somewhat specific to my own machine it's a build invocation for lovr and not luajit directly:
This is building with WolhSoft LuaJIT 113eb1d172dfb6b
(Notice minilua is being build debug despite me having picked BUILD_TYPE Release, but this hardly matters.)