Heads up...

General discussion regarding the OpenMW project.
For technical support, please use the Support subforum.
User avatar
psi29a
Posts: 3998
Joined: 29 Sep 2011, 10:13
Github profile: https://github.com/psi29a/
Contact:

Re: Heads up...

Post by psi29a » 27 Jun 2018, 13:38

Win10 MSVC2017 CI is online... it seems to be doing something:
https://gitlab.com/psi29a/openmw/-/jobs/77802439

we'll see what happens. *fingers crossed*

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

Re: Heads up...

Post by psi29a » 27 Jun 2018, 15:40

god I hate windows... so apparently, windows, by default, does not support paths longer than 260 characters. To enable this, you have to dig into regedit and set the bit from 0 to 1 to enable long path.

https://www.howtogeek.com/266621/how-to ... haracters/
^-- developer friendly my ass

Wasted a few hours on that little tidbit... why is this not standard?

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

Re: Heads up...

Post by Starsheep » 27 Jun 2018, 17:08

are all these jobs running on gitlab infrastructure?

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

Re: Heads up...

Post by psi29a » 27 Jun 2018, 17:29

Starsheep wrote:
27 Jun 2018, 17:08
are all these jobs running on gitlab infrastructure?
No, on mine.

GitLab provides shared docker runners (Linux), but that's it. Which is fine, but we need to support Mac and Win so I have those running in VMs. :)

Anyone can add one for us our code on... for example GNU/Hurd or FreeBSD or a PS4, doesn't matter.

https://docs.gitlab.com/runner/
^-- for those interested

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

Re: Heads up...

Post by Starsheep » 27 Jun 2018, 17:39

Well thanks for offering the horsepower!
Now we can figure out how much CO2-equivalent OpenMW consumes each time jobs are triggered

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

Re: Heads up...

Post by lysol » 27 Jun 2018, 17:45

Starsheep wrote:
27 Jun 2018, 17:39
triggered
(just kidding)
Normal mapped texture replacers, exclusive for OpenMW:
My Nexus page

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

Re: Heads up...

Post by psi29a » 27 Jun 2018, 18:07

Finally! It's building!
https://gitlab.com/psi29a/openmw/-/jobs/77880755

I've hit a few issues along the way, so I'll likely update our dev wiki soon.

msbuild is not, by default, in path... even if installed for us by msvc2017, Found some great information about it here:
https://stackoverflow.com/questions/406 ... a-bat-file

Our deps are downloaded from official websites... and break from time to time. I suggest we self-host our deps, this should also help our win devs to locate everything they need in one place. Case and point, the Qt 5.7 was pulled from the official website but put on their 'archive' page. This will cause our current CI scripts to fail. Appveyor does caching, but as soon as a build fails... boom, cache gone and script breaks.

The issue with the 260 max path is annoying, we can work around this with a regedit hack or key one can install.

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

Re: Heads up...

Post by AnyOldName3 » 27 Jun 2018, 18:54

The updated documentation I wrote for the CI script does mention the path length issue. You don't need the registry tweak if you put the repo closer to a disk root. The reason long path support is disabled by default is that people still like to write new Windows applications that call MSDOS APIs (e.g. functions that predate Windows being called by Fallout 4) and some of those APIs work with a 256-byte file path buffer and 3-byte file extension buffer, as that was bigger than anyone could conceivably need in the early 80s, and was faster and used less memory than making it vary based on what was needed. I guess Unix's designers either were more forward-thinking or they managed to convince their developers to stop doing stupid things.

Regarding finding MSBuild, it's not on the path as it's common that you'll have multiple versions of the Windows SDK and Visual C++ installed so you can optionally target older Windows versions. One MSBuild executable could conceivably be used with a range of Windows SDKs and a range of std library implementations, so it gets which one of each it's supposed to be using from environment variables. The content of these may change with Visual Studio and Windows updates, so you're meant to use a VCVars<x>.bat to set everything up properly. It's possible that in a few months, something will get updated, and calling MSBuild directly will do something silly, so I'd feel more comfortable if the script used vswhere to find where vcvars64.bat is, then called that, then used the MSBuild that gets put on the path.
AnyOldName3, Master of Shadows

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

Re: Heads up...

Post by psi29a » 27 Jun 2018, 21:02

Thanks for the explination, it's more or less what I gathered already from the documentation.

My original work-around was to install boost to C:\boost them mv that to where the gitlab-runner build dir was and in the link I posted also mentioned that vswhere is now included in msvc2017.3 and we should use that.

This will still need to happen anyway:
The official_releases of 5.7 no longer exists, the only reason our builds keep working is thanks to caching done by appveyor ;)

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

Re: Heads up...

Post by AnyOldName3 » 27 Jun 2018, 22:29

They must have changed that in the last week or two, as it was still up when I was updating the documentation.
AnyOldName3, Master of Shadows

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest