marcel303 / keen

Keen Dreams port using SDL
GNU General Public License v2.0
28 stars 2 forks source link

Building using Visual Studio on Windows #2

Closed fragmental closed 6 years ago

fragmental commented 6 years ago

I'm on Windows 10, using Visual Studio Community Edition 2017.

Using the solution and project files you provided here I added the files to my github clone, and then allowed visual studio to upgrade the project to the latest version. I then tried to build and it failed trying to find to find the files in the "static" directory. I know that the makefile will automatically compile those files, or you can compile them manually using "make data", but I don't know how to do that with visual studio. Here is a screenshot of the errors.

Also, the solution says that a "bin2c.vcxproj" is missing from the tools folder

marcel303 commented 6 years ago

Hi and thank you for the report. I've updated the CMake file to include Windows support specifically. Please use CMake to create project files for your preferred IDE, and try to compile it. I've verified it works using Visual Studio 2015 (Community Edition). Changelists: SDL and XInput build rules for WIndows: https://github.com/marcel303/keen/commit/78d49bf1a97011019e6511f5e519e346b797078a Workaround compile issues due to Visual Studio 2015+ incompatibility w/ SDL 1.x: https://github.com/marcel303/keen/commit/3d601698270bc23259d1f82594936e1b60da0475 SDL and XInput development files: https://github.com/marcel303/keen/commit/164f33b14a5ce06988a401b0c6813a8842a358c1

fragmental commented 6 years ago

Admittedly, I don't know what I'm doing. But here were the steps I took and the result.

In Visual studio:

  1. File>open>cmake - CMakeLists.txt Visual studio did some processing for a while
  2. Cmake>Build All Visual studio built the static files, but nothing else

Here is the output of the build

marcel303 commented 6 years ago
  1. Build succeeded.

Seems like you were successful actually. :-) You should have a kdreams.exe somewhere. Probably in 'where you told CMake to create the project file'\Debug or \Release.

If you get the game files and copy kdreams.exe there + SDL.dll and XInput.dll it should work!

fragmental commented 6 years ago

You would think so, but unfortunately those files and folders don't seem to exist. Unless visual studio stuck them in some very strange place, that wasn't in the git clone folder. Here is a list of the files that were created

marcel303 commented 6 years ago

Did you tell CMake to generate the project file at some different location perhaps? CMake is designed to use out of tree builds. Meaning the executables and intermediates etc get written to the CMake output location, instead of inside the source tree. I explicitly told it to put the generated headers and source files inside the source tree of course, but build products still go to the CMake output folder. It should generate a Debug or Release folder in there, depending on the type of build.

marcel303 commented 6 years ago

It looks like this on my machine,

image

marcel303 commented 6 years ago

I've pushed a few new changes that will set the working directory to 'keenrepository'/game (so you don't need to set it manually from within Visual Studio), and to copy the DLL files to the Debug and Release output folders (so again, you don't have to do this manually). This should make running on Windows quite easy. Just generate the project using CMake, copy the game files to 'game', open the generated project file, make sure 'kdreams' is selected as startup project, and build-and-run (F5).

fragmental commented 6 years ago

Ha. I found it. It was the "CMakeBuilds" folder inside the home folder. That must have been the default working directory. All the other stuff is there too.

marcel303 commented 6 years ago

Ok great. Let me know if the updated CMake file works for you. You should be able to run it more easily from Windows now.

fragmental commented 6 years ago

Visual Studio still seems to want to put everything in the same folder. I even made sure to remove all of the changed files so no settings could linger.

this is the folder https://i.imgur.com/pbXbGp0.jpg The Debug and Release folders both seem to contain copies of SDL.dll and XInput9_1_0.dll

It seems as though visual studio initializes the CMake working folder based up its own defaults. I might have found a way to change that by changing "buildRoot" in "CMakeSettings.json", but that looks like it's a global change. https://blogs.msdn.microsoft.com/vcblog/2016/10/05/cmake-support-in-visual-studio/#configure-cmake

I also haven't found a way to run CMake from a command prompt. I don't think Visual Studio's implementation of CMake provides for that.

The exe that was created does seem to work, however.

marcel303 commented 6 years ago

Whoah! I was going to ask which version of CMake you use, since the folder structure looks very different from what I know. But then I read the article you linked and learned Visual Studio has built in CMake support these days. Wow. Didn't imagine that. Learned something new today.

I'll look into fixing the DLL locations. I was assuming CMake's standard folder structure when creating a Visual Studio project, not this structure Visual Studio uses.

To use CMake from the command prompt or as a GUI you'll need to download CMake from its official website. It's just a small standalone application and you can use it from the command line too.

marcel303 commented 6 years ago

Ok, I added a custom build step which should fix the issue with DLLs ending up in the wrong locations, https://github.com/marcel303/keen/commit/c53a93aba41cd5a28c4a0898e6770c87b4323188. It should work fine now. I read up on it and I think it's ok now. It's expected VS puts those files there. Changing the build root also seems fine if you want to put the build products in a more 'deterministic' place. Could you try this?

Also, a big thank you for your efforts! It's helping me to improve the build a lot!

fragmental commented 6 years ago

You're welcome. I tried changing the Build Root from "${env.USERPROFILE}\\CMakeBuilds\\${workspaceHash}\\build\\${name}" to "${CMAKE_CURRENT_SOURCE_DIR}\\Builds\\${workspaceHash}\\build\\${name}" and instead it stuck it in C:\Users\Bradley\CMakeBuilds\-1512102639\build\x86-Release. The workspace hash is a little different though. It usually looks like a524a1bc-acbe-1a39-bf31-f44766c57281 instead of -1512102639, which is kind of weird. I'm not really concerned with where it puts the executable, though, as long as I can find it.

marcel303 commented 6 years ago

I'd just set it to D:\ProjectFiles\KeenDreams\ or something. I like to have my project files organized together so it's easy to start working on them. Also I put them on D because I have a really small SSD. ;-) But, ultimately, it doesn't really matter so much. I'm closing this issue as the CMake project seems to work now!