search

DFHack / dfhack

Memory hacking library for Dwarf Fortress and a set of tools that use it
Other
1.86k stars 468 forks source link

Does anybody know why I cant compile 047.04.-alpha? #1518

Closed LordBSD closed 4 years ago

LordBSD commented 4 years ago

λ cmake ..
-- Selecting Windows SDK version 10.0.18362.0 to target Windows 10.0.18363.
CMake Error at CMakeLists.txt:58 (message):
MSVC 2015 or 2017 is required

CMake Warning (dev) at CMakeLists.txt:376 (find_package):
Policy CMP0074 is not set: find_package uses _ROOT variables.
Run "cmake --help-policy CMP0074" for policy details. Use the cmake_policy
command to set the policy and suppress this warning.

CMake variable ZLIB_ROOT is set to: 

C:/Users/jdion/Downloads/dfhack/build/depends/zlib/

For compatibility, CMake is ignoring the variable.
This warning is for project developers. Use -Wno-dev to suppress it.

-- JsonCpp Version: 1.8.4
-- Looking for C++ include clocale
-- Looking for C++ include clocale - found
-- Looking for localeconv
-- Looking for localeconv - found
-- Looking for C++ include sys/types.h
-- Looking for C++ include sys/types.h - found
-- Looking for C++ include stdint.h
-- Looking for C++ include stdint.h - found
-- Looking for C++ include stddef.h
-- Looking for C++ include stddef.h - found
-- Check size of lconv
-- Check size of lconv - done
-- Performing Test HAVE_DECIMAL_POINT
-- Performing Test HAVE_DECIMAL_POINT - Success
-- Configuring incomplete, errors occurred!
See also "C:/Users/jdion/Downloads/dfhack/build/CMakeFiles/CMakeOutput.log".
See also "C:/Users/jdion/Downloads/dfhack/build/CMakeFiles/CMakeError.log".
C:\Users\jdion\Downloads\dfhack\build [develop ≡ +0 ~1 -0 !]
λ

Why is it saying MSVC 2015 or 2017 is required if I have visual studio 2019? Thanks I appreciate you guys always helping me as im still learning.

lethosor commented 4 years ago

The error doesn't mean "2015 or 2017 or newer" - the check is for a specific range of versions, and won't allow anything newer or older. I don't build on Windows so I don't know if VS2019 works or not, but BenLubar or someone else might.

BenLubar commented 4 years ago

If you want to try building on VS2019, change the 1919 on line 58 of CMakeLists.txt to 1929. It might work, or it might break horribly.

brndd commented 4 years ago

Why is it saying MSVC 2015 or 2017 is required if I have visual studio 2019? Thanks I appreciate you guys always helping me as im still learning.

Because 2019 isn't the same as 2015 or 2017. Visual Studio is weird like that.

You can install older build tools by running the Visual Studio Installer (if you have Visual Studio installed, you probably also have this installed; try searching for it using Windows search), then clicking on "More" next to Visual Studio, selecting "Modify", clicking on the "Individual components" tab, and enabling "MSVC v140 - VS 2015 C++ build tools" (or the 2017 one, if you prefer).

LordBSD commented 4 years ago

lol ok thanks ill try now. Can I build the windows dfhack on linux then? Id love to do that instead i didnt think i could do that. that's called cross compiling right?

LordBSD commented 4 years ago

Thank you all for your help but it seems I already have that installed. And you cant see it in the pic but if you were to scroll down it never goes up to 15 it only shows me up to v142. Thanks for the help https://imgur.com/a/IDKHqxj

lethosor commented 4 years ago

v142 is 2019, and v141 is 2017 - can you set Visual Studio to use v141 somehow? (I don't know how to do this, but I expect VS2019 defaults to v142.)

LordBSD commented 4 years ago

I did what brndd said to do and edited the cmake file it configured perfectly now I just have to figure out the commands to compile it as make and gmake give an error (does not exist.)

lethosor commented 4 years ago

Right, on Windows, CMake will generate a Visual Studio project by default, so make won't work. https://dfhack.readthedocs.io/en/latest/docs/Compile.html#windows should have more detailed instructions.

LordBSD commented 4 years ago

I just booted gentoo and had this running in two minutes. git clone https://github.com/DFHack/dfhack.git mkdir build && cd build git submodule update --init cmake .. make Thanks for the help and sorry for the noise, ill just do this on gentoo. I hate windows anyway. Thank you all for your help I really appreciate what you do with these programs and plugins to make DF more fun. It's appreciated.

lethosor commented 4 years ago

FYI, if you want faster incremental builds, replacing make with ninja might help: https://dfhack.readthedocs.io/en/latest/docs/Compile.html#generator

LordBSD commented 4 years ago

Yes I tried using ninja earlier because you recommended it a few days ago to me. but it failed so im taking it one step at a time. Im 42 years old it used to be simple. ./configure make make install. I suppose its still simple I just havent learned yet. Ill continue to read the links thanks for them.

brndd commented 4 years ago

You need to tell CMake to use the older build tools. I don't quite remember how this is done and don't have the build environment set up right now, but there should be an argument you can pass to it. Perhaps this page will help: https://cmake.org/cmake/help/v3.12/variable/CMAKE_GENERATOR_TOOLSET.html

Maybe this too: https://stackoverflow.com/questions/47154454/cmake-how-to-specify-vs2015-3-toolset-with-vs2017-installed

lethosor commented 4 years ago

To clarify, that's for Windows, and some of our Windows generate-* scripts specify v140 already

LordBSD commented 4 years ago

Thank you both for the help. I now successfully configured and generated the files using cmake-gui and the info in that stackoverflow link. However I am used to the old school ./configure ; make; make install. cmake is new to me. Now that the files are generated using cmake, I still don't see a make file was that supposed to get built? What is the proper make command I am getting command not found. I also tried gmake but it says no make file found. I installed gnu make but it says its not in my path. I am also struggling with certain perl modules. I tried both active perl and strawberry perl with cpan but no luck. I think I am just going to wait for the windows builds I hate hacving to bother you guys. Its so much easier on Linux. I don't know why windows has to be difficult but we all know that's nothing new. Thank you all so much for your help. I'll just wait for you guys. You seem to work really fast anyway.

brndd commented 4 years ago

https://docs.dfhack.org/en/stable/docs/Compile.html#windows the instructions here should get you going with compiling it on Windows. The generation scripts should create .bat files you can run to compile dfhack (or open to see the commands to do so yourself), and they also create a Visual Studio project file (.sln) that you can open in the Visual Studio IDE and compile from there.

LordBSD commented 4 years ago

Thanks I didn't want to have to give up for now, i'll read this, more and keep going. Thanks for the link.

LordBSD commented 4 years ago

Well I didnt want to give up and some of you guys inspired me to keep going. I installed the linux subsystem for windows, got a few perl modules going, hit a few barriers and overcame them. This is where I am now though, at a dead stop but the good news is im at 97% ....

[ 97%] Built target labormanager [ 97%] Linking CXX shared module RemoteFortressReader.plug.so /usr/bin/ld: cannot find -lSDL collect2: error: ld returned 1 exit status make[2]: [plugins/remotefortressreader/CMakeFiles/RemoteFortressReader.dir/build.make:223: plugins/remotefortressreader/RemoteFortressReader.plug.so] Error 1 make[1]: [CMakeFiles/Makefile2:5034: plugins/remotefortressreader/CMakeFiles/RemoteFortressReader.dir/all] Error 2 make: *** [Makefile:152: all] Error 2 root@CORE:/mnt/c/Users/jdion/Downloads/dfhack/build#

Please let me know if you have an idea how I may continue. I hit problems like this and was able to search for the packages and install them because of the linux subsystem i chose debian which is a dist i am comfortable with, but now this. what is -ISDL? thanks.

LordBSD commented 4 years ago

It compiled thanks guys, for the help. I had to install a few SDL packages in the linux subsystem.

thurin commented 4 years ago

Be sure you're following https://docs.dfhack.org/en/stable/docs/Compile.html it has dependencies and instructions for the different platforms.

LordBSD commented 4 years ago

Yes thurin I realize now i was foolish. I thought compiling it in the windows linux subsystem would get me a binary for windows but I see now that's not how that works. I followed the link you provided, and ran cmake .. after getting over the hurdles I went with the previous posters help, but now I face this trying to compile using the .sln built. Here is an image of the errors I get while compiling. Are these my errors or?

https://imgur.com/a/CmkWrdx

thurin commented 4 years ago

I've never tried to compile from inside VS. It looks like you're using 2019? I'm pretty sure it requires a 2015 or 2017 toolchain to build. I'm not sure if that's what's contributing to your compile errors or not.

Here's what I do to build it. I've installed the 2015 msbuild tools even though I have VS2019 that I use daily. I follow the command line instructions in the linked compile docs. From the build\win64 folder I use the set_df_path.vbs to create the DF_PATH.txt files used by the .bat files. I run generate-MSVC-release.bat to create the VC2015 folder with all its cmake and project files. Then i run install-release.bat to compile and install to the chosen path.

PatrikLundell commented 4 years ago

If I remember correctly, you need 2015 support installed for 2017 (and I think that was on top of the everything and the kitchen sink installation option) to work, and assume that goes for 2019 as well. That's on top of the directive to use 2015. I can compile within MSVC, but that won't get the stuff to the DF folder, so local compilation there is for testing that modified code compiles, and can be used for a single item that's then moved manually. For the "real" compilation passes I use the install-debug bat file. Also note that when modifying XML files I have to use MSVC to clean everything, or the bat file will not rebuild everything that should be rebuilt, resulting in error reports about usage of things that were removed/renamed.

LordBSD commented 4 years ago

Thanks guys ill keep trying with what you said. I appreciate it.

lethosor commented 4 years ago

I'm going to close this for now, but feel free to let us know if you run into anything else

jeancallisti commented 4 years ago

I've been trying to build DFHack with Visual Studio 2019 and I understand the gist of everything above, I even think I'm very close, but I'm hitting a silly wall.

What I've done:

It seems to run CMake with no errors, and it builds zlib, SDL, etc. A very good start.

But now I'm trying to run CMakeLists.txt in real conditions for DFHack, with the options from generate-...-.bat. I follow these steps :

My issue : I must be too dumb to understand CMake's user interface, but when I click on Configure it tries to run CMake straight away instead of opening the window first (the window that lets me choose the compiler). As a result, it fails because it's using the wrong compiler. Duh.

What am I doing wrong?

Alternatively I've tried this :

And indeed, after that, DFHack compiles perfectly in Visual Studio and I can run INSTALL which copies everything to my DF folder (47_04_win) and applies the DFHack patch, but then Dwarf Fortress.exe is corrupt and won't run anymore. Proof that I'm missing a critical compiler setting.

lethosor commented 4 years ago

but then Dwarf Fortress.exe is corrupt and won't run anymore. Proof that I'm missing a critical compiler setting.

What error message are you seeing that indicates this? DFHack actually doesn't modify the DF executable at all - it replaces SDL.dll to load itself on Windows. My initial guess is that you're compiling 64-bit DFHack for 32-bit DF, or vice versa, so I would suggest double-checking that the architectures match on your end.

I've never used the CMake GUI before (or built on Windows, for that matter, so I won't be much help there). I would personally prefer the batch scripts in the build folder, but it sounds like you've tried those already.

thurin commented 4 years ago

Not sure if it's helpful, but here's my simplified build.bat file which is really just a combination of the generate-MSVC-release.bat and install-release.bat with minor tweaks like -T v140 instead of -T v140_xp. I run this from a VS2015 x64 Native Tools Command Prompt from the build\win64 directory. DF_PATH.txt contains the path to the Dwarf Fortress install directory.

SET VCTargetsPath=C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140

IF EXIST DF_PATH.txt SET /P _DF_PATH=<DF_PATH.txt
IF NOT EXIST DF_PATH.txt SET _DF_PATH=%CD%\DF

IF EXIST VC2015 rmdir /S /Q VC2015

mkdir VC2015
cd VC2015

cmake ..\..\.. -G"Visual Studio 14 Win64" -T v140 -DCMAKE_INSTALL_PREFIX="%_DF_PATH%" -DBUILD_DEVEL=0 -DBUILD_DEV_PLUGINS=0 -DBUILD_DOCS=1 -DBUILD_STONESENSE=1

msbuild /m /p:Platform=x64 /p:Configuration=Release INSTALL.vcxproj

cd ..

This does a clean release install build.

I've never tried building from the gui or VS since this works for me so I'm not much help debugging those routes.

jeancallisti commented 4 years ago

EDIT :

Thanks to Thurin's advice, I now understand better the meaning of the parameters.

Two possible roads if you are like me a user of Visual Studio 2019

Use VS 2017 tools

Use VS 2015 tools

I personally chose the VS2017 approach as I was experiencing this (unexplained) issue with the VS 2015 approach : https://stackoverflow.com/questions/52569137/error-msb4062-the-setenv-task-could-not-be-loaded-from-the-assembly

I will now go back to trying to build release and see if it still makes DF "corrupt" for me like it did before.

lethosor commented 4 years ago

Worth noting that @ragundo recently ran into an issue where DFHack would crash on startup when using the v141 compiler (2017), and switching to v140 (2015) fixed it. I'm not sure if you will run into the same issue, but I would encourage using 2015 if you're able to.

ragundo commented 4 years ago

As @lethosor says, until the latest release I was able to use toolset v141 with DFhack sucessfully, but I needed to use now toolset v140 for making it work becasue if not, DFhack crashed inmediatily after start. I have VS2017 installed in my system.

The workflow is always the sama:

And my generate-MSVC-minimal.bat

cmake ..\..\.. -G"Visual Studio 15 2017 Win64" -T v140 -DCMAKE_INSTALL_PREFIX="%_DF_PATH%" -DBUILD_DEVEL=0 -DBUILD_DEV_PLUGINS=0 -DBUILD_STONESENSE=0 -DFHACK_BUILD_ARCH=64 -DCMAKE_BUILD_TYPE:string=RelWithDebInfo

I use fantastic Visual Studio Code to do all the work in Windows and only use Visual Stuido 2017 for debugging. For using Visual Stuido Code, just start it, open the dfhack folder, open a Terminal windows and change to the build/win64 directory. From there you can run all the .bat files and see the cmake/compiler output, with the advantage that you can open error lines in the editor. Prety dope.

jeancallisti commented 4 years ago

I myself have better luck with Visual Studio 2017 (for the reasons I explained, which have nothing to do with DFHack but more with Windows mysteries). After the initial generate using CMake, I then build inside Visual studio and also run the PACKAGE script from VS. I don't seem to encounter any issue.

alef commented 3 years ago

This is how I built and tested in latest Visual Studio 2019 by using the 2015 built tools, as in @brndd comment:

"MSVC v140 - VS 2015 C++ build tools"

cmake source dir -G"Visual Studio 16 2019" -T v140 -DDFHACK_BUILD_ARCH=64 -DCMAKE_INSTALL_PREFIX=wherever

Then I run:

"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\amd64\msbuild.exe" with arguments: -m -t:Build -p:Configuration=RelWithDebInfo -p:Platform=x64 INSTALL.vcxproj

The keys are to use the generator for 2019 but specifying v140 as toolkit, as hinted in last comment here.

lethosor commented 3 years ago

Ah, you're using the same generator that caused issues in https://github.com/DFHack/dfhack/issues/1715#issuecomment-735246141 - I take it that's why you're specifying DFHACK_BUILD_ARCH as well.

Ideally, our build scripts (like this one) could be updated to handle VS2017/2019. Updating our Windows build documentation would also be good - I don't think it explains how to use msbuild at all currently. Do you know if the build folder you made would also work from Visual Studio? (I assume it would, because your cmake command is pretty similar to what our existing build scripts use.)

Update: it also looks like including "Win64" in the generator name is only supported for the VS2015 generator - the new way is by setting CMAKE_GENERATOR_PLATFORM, e.g. with -A Win64, so we should probably support that too.

alef commented 3 years ago

@lethosor

... I take it that's why you're specifying DFHACK_BUILD_ARCH as well.

No, just one of the many random attempts to get it working.

... Do you know if the build folder you made would also work from Visual Studio?

Yes, it does.

lethosor commented 3 years ago

Ah, well, since we currently determine the architecture from the generator name, you'd need it in any case.

Thanks for checking on Visual Studio! I'll open a new issue to keep track of Windows build-related/documentation updates, and I'll try to remember to ping you once we've made changes.