Topic: Building WL on win 10
hessenfarmer Topic Opener |
Posted at: 2018-08-26, 00:12
looks good so far. only that it is recommendable to use the msys2 shell related to the mingw toolchain due to most of the path settings optimized for them. so use the mingw64.exe or the mingw32.exe instead of msys2.exe After I ahve figured out how to use innosetup I plan to add the instructions on how to make an installer as well. Currently one need to select the dll by hand or use them from an existing installation. Top Quote |
GunChleoc |
Posted at: 2018-08-26, 11:13
Important point - using the Busy indexing nil values Top Quote |
hessenfarmer Topic Opener |
Posted at: 2018-08-26, 15:33
another advantage of using the mingw64.exe is that it is automatically setting the path to the mingw bin folder. So you don't have to do the path export everytime. So I think this should be standard to use the optimized shell. However we should probably add some explanation about the cmake options used. especially we should explain how to change the compiled version and the usage of glbinding or glew. Perhaps we could link to the linux instructions where they are explained. Top Quote |
GunChleoc |
Posted at: 2018-08-26, 17:17
+1 to linking to the CMake page. We should also link to the BzrPrimer. Busy indexing nil values Top Quote |
Tino |
Posted at: 2018-08-28, 11:09
The manual selecting of the needed dlls is very error prone, as you can see with the appveyor builds: often with new versions the names and/or dependencies change and you have to remove/change/update dlls... My suggestion (if anyone wants to dive deeper into this): Figure out, how to do static builds, so you'll have only the widelands.exe which needs to be put into the installer. I've done this with the Nuwen distro, but only in a manual way (and every distro upgrade is a pita...):
The main problem is (regarding the msys2 distro) that although every library is available dynamic and static, all the cmake scripts prefer the dynamic version. Only Boost is linked statically (we have a switch for this in our CMAKE file). So if anyone figures out how to teach CMAKE to prefer static libs (for SDL,ICU...) we would just have to package the .exe and no "dll hell". I've tried this for years now, but never succeeded (apart from "removing" the dynamic libs and manually fiddling with the linking...) Top Quote |
fuchur |
Posted at: 2019-05-10, 21:13
Just a few comments to the excellent build instructions.
Apart from that I'm looking forward for the first build as soon I have a solution for the cmake errors (see https://wl.widelands.org/forum/post/27897/). Top Quote |
GunChleoc |
Posted at: 2019-05-11, 11:45
That's what I usually do too, so I won't have to deal with any errors because something is missing. I decided that testing what we really need would be too time-consuming for me.
SirVer implemented that when he modernized the software renderer. I never researched the details myself. Busy indexing nil values Top Quote |