Windows Pre-build Script Documentation Updated

Everything about development and the OpenMW source code.
wheybags
Posts: 207
Joined: 21 Dec 2012, 19:41

Re: Microsoft Buys Github for $7.5 Billion

Post by wheybags » 07 Jun 2018, 13:02

Also, maybe moving all these windows dev posts to a new thread makes sense?

User avatar
psi29a
Posts: 4037
Joined: 29 Sep 2011, 10:13
Github profile: https://github.com/psi29a/
Contact:

Re: Microsoft Buys Github for $7.5 Billion

Post by psi29a » 07 Jun 2018, 13:10

wheybags wrote:
07 Jun 2018, 13:02
Also, maybe moving all these windows dev posts to a new thread makes sense?
I'll split these over to AnyOldName3's post... and done.

User avatar
wareya
Posts: 189
Joined: 09 May 2015, 13:07

Re: Windows Pre-build Script Documentation Updated

Post by wareya » 07 Jun 2018, 13:12

The Qt download for the CI script froze for me, the filesize got to 250MB and stopped increasing. I had to stop the script (with ctrl+c), delete the qt archive/executable, and then rerun the script.

I didn't have 7z in my path so the bullet extraction step just failed silently without any visible error.

The qt extraction step invoked a graphical installer.

The SDL2 extraction step failed for no discernible reason but worked when I reran the script.

The configure step failed because msbuild.exe wasn't in my path. Once I added it it failed because it was looking for microsoft.cpp.default.props in the wrong place.

Switching from 2017 to 2015 causes it to reacquire and reinstall all the dependencies, including qt, which I'll emphasize is a graphical installer again.

After switching to 2015 it failed to find bullet:

Code: Select all

-- Configuring OpenMW...
-- Using Qt5
-- Found FFmpeg_AVCODEC
-- Found FFmpeg_AVFORMAT
-- Found FFmpeg_AVUTIL
-- Found FFmpeg_SWSCALE
-- Found FFmpeg_SWRESAMPLE
-- Boost version: 1.61.0
-- Found the following Boost libraries:
--   system
--   filesystem
--   program_options
--   locale
-- Found MyGUI 3.2.2
-- Found SDL2 2.0.7
-- Found Bullet_BulletCollision
-- Found Bullet_LinearMath
CMake Warning (dev) at cmake/LibFindMacros.cmake:92 (message):
  Unable to find 'LinearMath/btScalar.h'
Call Stack (most recent call first):
  cmake/LibFindMacros.cmake:131 (libfind_header_path)
  cmake/LibFindMacros.cmake:189 (libfind_version_n_header)
  cmake/FindBullet.cmake:64 (libfind_version_header)
  CMakeLists.txt:253 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Error at C:/Users/wareya/Desktop/git/cmake/share/cmake-3.9/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
  Could NOT find Bullet: Found unsuitable version "", but required is at
  least "286" (found
  optimized;C:/openmwdev/openmw/MSVC2015_64/deps/Bullet/lib/BulletCollision.lib;debug;C:/openmwdev/openmw/MSVC2015_64/deps/Bullet/lib/BulletCollision_Debug.lib;optimized;C:/openmwdev/openmw/MSVC2015_64/deps/Bullet/lib/LinearMath.lib;debug;C:/openmwdev/openmw/MSVC2015_64/deps/Bullet/lib/LinearMath_Debug.lib)
Call Stack (most recent call first):
  C:/Users/wareya/Desktop/git/cmake/share/cmake-3.9/Modules/FindPackageHandleStandardArgs.cmake:375 (_FPHSA_FAILURE_MESSAGE)
  cmake/FindBullet.cmake:66 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  CMakeLists.txt:253 (find_package)
paying attention to #1751/#1816 #2473 #3609 #3862/#3929 #3807 #4297

User avatar
AnyOldName3
Posts: 983
Joined: 26 Nov 2015, 03:25

Re: Windows Pre-build Script Documentation Updated

Post by AnyOldName3 » 07 Jun 2018, 14:20

The Qt download for the CI script froze for me, the filesize got to 250MB and stopped increasing. I had to stop the script (with ctrl+c), delete the qt archive/executable, and then rerun the script.
It's grabbing the official installer from the official download location, so if that happened it shouldn't be because the server went down. The download itself is done via curl with sensible options to make it retry if the download fails, though, so that should be fairly robust. Looking at things, I'd guess that curl still thought it was doing something sensible when you force killed it, but we have no way of knowing what unless someone happens to have the exact same issue while running the script in verbose mode.
I didn't have 7z in my path so the bullet extraction step just failed silently without any visible error.
I'm going to add better error messages for that kind of thing.
The qt extraction step invoked a graphical installer.
At some point, Qt made their installer ignore the --silent option. I think it can be made silent again with the qs installer, but I don't know how, and don't think it's a priority.
The SDL2 extraction step failed for no discernible reason but worked when I reran the script.
That's definitely weird.
The configure step failed because msbuild.exe wasn't in my path. Once I added it it failed because it was looking for microsoft.cpp.default.props in the wrong place.
You should definitely never have msbuild.exe in your path unless you're only doing it for that one session via a vcvars batch file (as otherwise the ten zillion environment variables it depends on won't be set and it won't be able to do stuff like find microsoft.cpp.default.props). This issue is just CMake being CMake as it's supposed to work out which executables it needs and where they are on its own. Sometimes it fails, though, and I'm pretty sure you're supposed to report these failures to Kitware instead of trying to work around them yourself.
Switching from 2017 to 2015 causes it to reacquire and reinstall all the dependencies, including qt, which I'll emphasize is a graphical installer again.
When you run it in 2017 mode, it downloads libs and dlls built with VC 2017, which can only be linked against by VC 2017. If you need to link against libs with VC 2015, of course it's going to need a different version of them.
After switching to 2015 it failed to find bullet:
I can't tell if this is CMake's fault or our fault, but I'm leaning towards it being CMake's fault if C:/openmwdev/openmw/MSVC2015_64/deps/Bullet looks like it has the right stuff. Alternatively, if you have msbuild in your path still, that can cause this kind of problem, too.
AnyOldName3, Master of Shadows

User avatar
wareya
Posts: 189
Joined: 09 May 2015, 13:07

Re: Windows Pre-build Script Documentation Updated

Post by wareya » 07 Jun 2018, 14:26

I updated cmake and the bullet error went away, presumably the msbuild issue wouldn't happen anymore either.

Had to edit build.msvc.sh to do VS 2015 because I couldn't figure out what it expected for me to get it to use 2015 instead of 2013 via command line flags. (I only have the VS 2015 command line tools installed, not the IDE.)
paying attention to #1751/#1816 #2473 #3609 #3862/#3929 #3807 #4297

User avatar
AnyOldName3
Posts: 983
Joined: 26 Nov 2015, 03:25

Re: Windows Pre-build Script Documentation Updated

Post by AnyOldName3 » 07 Jun 2018, 14:43

From the IDE, building is as simple as right-clicking on the project you want to build and choosing build, so I'd imagine building from the command line would require you to use vcvars64.bat to get msbuild on the path and then you could just msbuild whichever project file you wanted.
AnyOldName3, Master of Shadows

User avatar
AnyOldName3
Posts: 983
Joined: 26 Nov 2015, 03:25

Re: Windows Pre-build Script Documentation Updated

Post by AnyOldName3 » 07 Jun 2018, 15:36

I've added some error messages to the CI script in this PR: https://github.com/OpenMW/openmw/pull/1731
AnyOldName3, Master of Shadows

User avatar
lysol
Posts: 962
Joined: 26 Mar 2013, 01:48
Location: Sweden

Re: Windows Pre-build Script Documentation Updated

Post by lysol » 07 Jun 2018, 22:34

Glad to see some work getting done to this issue. Sad to see the heated climate.

Guys, of course we all want to see better Windows support. We can help each other to reach that goal together (kumbaya), but complaining and being sarcastic at the devs just polarizes the entire situation to a Unix vs Windows developer flame war. Nobody wanted that. Aggressiveness creates defensiveness.

There's a reason why it is a bit hard to set up the windows build environment today, and it just boils down to the fact that most developers during the years have been Linux users. It's not a conspiracy. There's no hostility towards windows developers, that would be stupid. But really, think about it: All of the main devs, until AnyOldName3 came around, was purely linux or mac users. Why would any one of them put time and effort to fix stuff on an operating system they don't even own? They can't even test the stuff. Ace is mostly a linux user (IIRC), but has been making the windows builds anyway because he can.

So can we just continue this good path; AnyOldName3 working on fixing stuff that NullCascade and Wareya, and preferably others too, report your problems instead of just being sarcastic and insinuate that OpenMW has some sort of conspiracy going on against Windows devs. This is not true.
Last edited by lysol on 08 Jun 2018, 08:41, edited 1 time in total.
Normal mapped texture replacers, exclusive for OpenMW:
My Nexus page

User avatar
AnyOldName3
Posts: 983
Joined: 26 Nov 2015, 03:25

Re: Windows Pre-build Script Documentation Updated

Post by AnyOldName3 » 07 Jun 2018, 23:32

If we had a keen developer on any platform and they were to redo the CMake in the style advised by this blog (https://pabloariasal.github.io/2018/02/ ... ake-right/) I'm pretty sure it would resolve most of the issues we have on Windows (excluding the bother of actually acquiring the dependencies).

Out of our main dependencies, Boost and probably Qt support this already, but Bullet, FFMPEG, MyGUI and OSG would all need work. It's possible that we might be able to wrap the built-in versions from CMake with the versions in our /cmake/ directory without having to volunteer to rewrite the whole build system for all of our dependencies.

The main draw of using CMake instead of something else is that it's fairly ubiquitous among cross-platform projects, so we don't have to reinvent the wheel for each dependency, but if we're rewriting a bunch of things we lose this benefit. We really just need someone who really likes build systems to burn a couple of years of their lives on making a nice build system for everything.
AnyOldName3, Master of Shadows

User avatar
Starsheep
Posts: 54
Joined: 06 Jun 2018, 16:09

Re: Windows Pre-build Script Documentation Updated

Post by Starsheep » 14 Jun 2018, 16:08

From a not-much-of-a-developer point of view, just a code lurker/tools explorer/sometimes scripter: everything went super fine from the toolchain installation to the final build on a Win10 system.

Installing VS2017 is really a two clicks thing nowadays. Cloning the repo, adding 7z and CMake in my Path was trivial and once the Cl script had done its job, the longest part was downloading that monster thing that is Qt, and building the whole solution (without openmw-cs) took something like 10 minutes and everything was in working order, from the layout in the solution explorer to the final build that was just like Ace's nightlies.

After reading that whole "conversation", I don't get why it's a thing to say the dev environment is not windows friendly. It didn't even take me an hour to read the wiki, collect and run everything. The current setup is pretty idiot-proof considering this testimony comes from someone with not much coding experience.

Post Reply

Who is online

Users browsing this forum: lysol, Thunderforge and 6 guests