search

andy-thomason / Vookoo

A set of utilities for taking the pain out of Vulkan in header only modern C++
MIT License
524 stars 52 forks source link

Allow running on Mac OS X with MoltenVK #19

Closed FunMiles closed 4 years ago

FunMiles commented 4 years ago

I tried this library because it follows a similar approach I had followed in one of my projects but also is further along than I am in my project. So I would rather use this library and contribute to improving it than just continue with my code.

I work mostly on MacOS and discovered Vookoo when porting my app to Linux. I went back to MacOS X and tried to run the Vookoo examples. However they do not run. I have made some fixes and will submit a pull request for it. Modifications are limited to:

The last one brings my question before I submit a pull request: Why are there glfw3 includes in this project instead of relying on the glfw3 installed on whatever machine? glfw3 does a correct install with the cmake files and a find_package(glfw3) should work correctly. With a modern CMake (possibly before 3.1.3 as required in the CMakeLists.txt), getting the include directory only requires the use of: target_link_libraries(${order}-${exname} glfw3) which is in the CMakeLists.txt already.

I can check on Linux but have not yet tried on Windows, so if someone who is better versed in Windows than I am can chime in, I'd appreciate it.

PS: I guess I was also surprised to find in a github project that binary libraries are present in the repository. It is probably the reason why the glfw3 includes are there. However, why not include glfw3's source if Vookoo wants to install without any other external dependencies than Vulkan? This to me would be a satisfactory solution as well (and using git subrepo for including glfw3). The source of glfw3 is fairly small. I can put the git subrepo of glfw3 in my pull request or in a separate pull request.

lhog commented 4 years ago

I think similarly to other projects, we should move external libs to be git submodules as you seem to suggest. I will be able to test your PR on Windows and possibly on some Linux.

FunMiles commented 4 years ago

@lhog I am more for using git subrepo than submodules. git subrepo avoids some of the pitfalls of submodules. I've been using it in my own projects and so far have been quite satisfied with it. With subrepo, users do not need to worry about which version of the submodules or don't even need to worry that part of the project is under subrepo. They only clone the project and get everything transparently.

andy-thomason commented 4 years ago

I do prefer subrepo to submodules, too. But it does require an extra install step to git to use. We could experiment with this if you like.

Meanwhile, I've merged @FunMiles Mac port. I'll see if we can put some CI testing in place.

lhog commented 4 years ago

I agree. As much as subrepo might be better, as long as it's not standard to git itself, it should not be used as it makes end-user experience suffer.