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

Unable to build project #4

Closed
peter-r-g opened this issue Jan 5, 2023 · 4 comments
Closed

Unable to build project #4

peter-r-g opened this issue Jan 5, 2023 · 4 comments

Comments

@peter-r-g
Copy link
Contributor

I have been trying to get this project built but I cannot seem to get it working. I have been jumping down a rabbit hole of issues that I will detail below in the order I encountered them. Fair warning, I am quite new when it comes to C++ and its environment.

Release mode "Debug Information Format" option

Currently, the mentioned option is set to "Program Database for Edit And Continue (/ZI)" which prevents a build from happening because of the following error: /ZI' and '/GL' command-line options are incompatible. My solution was just to disable the option.

VCPKG package locations

Right now the Native > Host project expects the VCPKG packages to be installed at $(VcpkgRoot)\installed\$(Platform)-windows. Multiple issues with this when it comes to the latest version of VCPKG. The "VcpkgRoot" environment variable does not exist; The only one that seems to be used is "VCPKG_ROOT". Additionally, the directory "installed" under that root is never created. VCPKG instead creates a "vcpkg_installed" directory in the current working directory that you run the command; Which in this case is the same directory that the setup.cmd file is in. The solution to this would be to move the setup.cmd and vcpkg.json files into the solution directory and edit the external include directory to this: $(SolutionDir)vcpkg_installed\$(Platform)-windows\include\SDL2.

VCPKG setup broken for x64

For a reason that I cannot figure out when using the provided setup file. It will add all of the x86 packages but for x64 it will throw a shared directory in there and none of the packages. Because of this, on x64 you will not get any of the packages and fail to build. The current solution I have come up with is to make two separate setups for both x86 and x64 like so: vcpkg install --triplet=(x64/x86)-windows

VCPKG Packages not included

The current setup of Native > Host does not actually include any of the packages except for a portion of SDL2. Fixing this is just adding an extra entry without the "SDL2" directory: $(SolutionDir)vcpkg_installed\$(Platform)-windows\include.

VCPKG Missing packages

The vcpkg.json for Native > Host appears to be missing a couple of entries. From what I can tell it is missing the following packages: nethost, nlohmann-json, sdl2-image.

VulkanSDK

Currently, the Native > Host uses a hard-coded include path to VulkanSDK 1.3.224.1. Instead, it should use the VULKAN_SDK environment variable like so: $(VULKAN_SDK)\Include.

FMT Versioning

With VCPKG it installs the latest available version of a package. The current version of FMT is 9.1.0. Using said version creates the following error: fmt::v9::detail::arg_mapper<context>::map': was declared deprecated (compiling source file logmanager.cpp). The solution to this is to enforce the FMT package being used is of version 8.1.1; Before the breaking change was introduced. Achieving this is done by editing the vcpkg.json like so:
Adding property builtin-baseline with the value being the latest commit hash your VCPKG was built with (I think?). For example: "builtin-baseline": "0d239eb4d32f125c3da90e612096b14a11ef1474"
Adding another property overrides as an array with a single object inside detailing the FMT version:

{
    "name": "fmt",
    "version": "8.1.1"
}

The end result should be something like the following:

{
    "name": "mocha",
    "version-string": "1.0.0",
    "description": "Mocha game engine",
    "builtin-baseline": "0d239eb4d32f125c3da90e612096b14a11ef1474",
    "dependencies": [
        "fmt",
        "glm",
        "glslang",
        "nethost",
        "nlohmann-json",
        "sdl2",
        "sdl2-image",
        "spdlog",
        "vulkan-memory-allocator"
    ],
    "overrides": [
        {
            "name": "fmt",
            "version": "8.1.1"
        }
    ]
}

Linker errors

This is the part where my lack of C++ knowledge kills my progress. I am unsure of where to go from this point but getting this far will show 76 "unresolved external symbol" errors. From what I can tell all of them come from the usage of items in packages. The list of errors is available on Pastebin here.

Conclusion

All the issues mentioned I have been resolving in my own fork of the project here and will make a PR when it is finished.

@xezno
Copy link
Member

xezno commented Jan 5, 2023

Hello!

Thank you for bringing these issues to my attention. I'm also new to using vcpkg and had no idea that some of this would be problematic. I appreciate you taking the time to look into and resolve most of them.

Regarding the "Debug Information Format" option in Release mode, I have not yet tested it on x86. However, I have had difficulty using the /ZI feature in the past, so I am not particularly concerned about its absence.

Regarding the problems with vcpkg, I believe that running the vcpkg integrate install command may help to resolve them. The VcpkgRoot environment variable is a Visual Studio macro that is set up when you run integrate. This should also fix the linker errors and make it unnecessary to add $(SolutionDir)vcpkg_installed\$(Platform)-windows\include. The inclusion of SDL2 was an exception due to specific issues with vcpkg's handling of SDL.

In terms of building for x64 or x86, my VCPKG_DEFAULT_TRIPLET environment variable is currently set to x64-windows. Unfortunately, it does not seem that there is a convenient way to set this on a per-manifest basis. In this case, I agree with you in that running vcpkg install --triplet=(x64/x86)-windows would likely be the best solution.

@peter-r-g
Copy link
Contributor Author

Doing vcpkg integrate install did introduce the environment variables to VS which is good. However, it did not make $(SolutionDir)vcpkg_installed\$(Platform)-windows\include unnecessary and it did not fix the linker problem.

@xezno
Copy link
Member

xezno commented Jan 5, 2023

Ok, that's odd. Could you try adding $(SolutionDir)vcpkg_installed\$(Platform)-windows\lib to Native > Host Properties under VC++ Directories > Libarary Directories? Should look like this:
image

Also I think these properties might need to be changed (highlighted in bold):
image

@peter-r-g
Copy link
Contributor Author

Builds now succeed! From what I can tell there were two issues. Firstly, the vcpkg section did not have the highlighted sections filled out. Also, I had the vcpkg.exe in a "bin" directory inside of the vcpkg root which seemed to cause a silent error somewhere in the chain so linking failed. With that out of the way, there are runtime problems to deal with. I will close this issue and open a new one to get the runtime errors dealt with. Thank you!

This was referenced Jan 6, 2023
@xezno xezno added this to the Initial Release milestone Mar 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants