building examples-native fails on Windows #188
Comments
|
You'd want to have the |
|
You might also try changing: That'll let cmake choose how to run the build instead of always calling |
kvark
added
type: bug
|
Changing the final MSVC is failing with |
|
Hello and thanks for creating this issue! I am also already doing research for this problem for about two weeks now. I think that I can shine some light on the problems you're encountering because I encountered them too. First of about the following part:
This is because "normally" the For us Windows users, when we have Visual Studio installed, we get complete compilers that are automatically chosen by CMake. It is possible to use MinGW64 for instance by using the Secondly about the following part:
I have encountered this problem too and I am always manually specifying the header file and library file to solve this temporarily in Visual Studio. I am not sure if this automatically links the header file and library file on Linux, but on Windows it doesn't. I am not really familiar with CMake too, but I've read that it was built for Linux and it is using Linux predefined paths to look up libraries like GLFW for instance, so that could be an issue. Did you already have had a working example ran successfully in Windows? |
Nope, this is my first time trying to build the examples on win10. I managed to get CMake to find the glfw3 libs with link_directories("c:/Program Files/glfw3/lib")But now the actual symbol resolution fails: And finally: So one issue is that CMake generates x86 build files by default, but on x86_64 most Rust users will be using an x86_64 toolchain. So I changed the generator: examples-native: lib-native $(FFI_DIR)/wgpu.h examples/hello_triangle_c/main.c
cd examples/hello_triangle_c && \
$(CREATE_BUILD_DIR) && \
cd build && cmake -G "Visual Studio 15 2017 Win64" .. && \
cmake --build .And here's what we get: I'm not sure where to go from here, but I would say there are a couple partial fixes:
|
I think it is not possible to automatically set it. I have to dig deeper in the CMake documentation. I have found this though: https://cmake.org/cmake/help/latest/variable/CMAKE_MODULE_PATH.html where you are able to specify where to search for on the computer I think at least.
I think we still need to give the user the option to even build x86, even if the system is x64. Maybe we could add a parameter or some equivalent for CMake. So that whenever you try to build the application, it will take its system architecture, but if you explicitly specify the architecture it is able to override it.
Like I above already mentioned it, but we should not set the -G parameter in the script, because there are many compilers that are able to be used, or it should be a configurable parameter then it should be flexible. Just like automatically setting the architecture and being able to override it, we could do the same for the compiler; taking the default compiler when no argument is passed, otherwise using the passed in argument. The best option to continue with those issues is to modify the script, but only so it affects Windows users and not the other platforms. I am not sure what the impact for them will be. I have available time to do research and modify the file with the above points, if not someone is already doing it. If you are, just let me know, then I might be able to help.
And that is exactly where I am already stuck for over a week. The unresolved external symbols are coming from the Edit 1# |
|
Alright I have a working hello_triangle_c, on Windows! I have traced every missing reference and added the necessary See result: Doing this manually on Windows would be the hurdle to do for now. However, I have good news, solving this got me a strong motivation to continue pushing. I will try to fix and link this in the Makefile for Windows only, as I assume that Linux and OSX work. I hope today, or at least tomorrow to have the fix, so we can continue doing what we love most: solving problems! Edit 1 Source that helped me fix this: |
192: add necessary windows lib files for vulkan, dx12, dx11 r=kvark a=Napokue Introduce new argument BACKEND to specify the back-end framework in the hello_triangle_c CMake script. I will update the other examples, hello_remote_c & hello_compute_c (working on this one) in a future PR. fix #188 Co-authored-by: Timo de Kort <dekort.timo@gmail.com>
* Fix lexer operator issues (with tests) * [glsl-in] Don't convet to string in lexer tests * [glsl-in] cleanup lexer tests further - Consolidate use statements - Iterate lex directly, check for None at end
Running
make examples-nativefrom the project root:It looks like the
Makefileexpects CMake to have generated another Makefile:But on Windows (or at least my system) CMake generates Visual Studio project files instead.
I'm not terribly familiar with CMake so I'm not sure how to make it generate Makefiles instead.
The text was updated successfully, but these errors were encountered: