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*
Heads up...
- psi29a
- Posts: 5361
- Joined: 29 Sep 2011, 10:13
- Location: Belgium
- Gitlab profile: https://gitlab.com/psi29a/
- Contact:
- psi29a
- Posts: 5361
- Joined: 29 Sep 2011, 10:13
- Location: Belgium
- Gitlab profile: https://gitlab.com/psi29a/
- Contact:
Re: Heads up...
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?
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?
Re: Heads up...
are all these jobs running on gitlab infrastructure?
- psi29a
- Posts: 5361
- Joined: 29 Sep 2011, 10:13
- Location: Belgium
- Gitlab profile: https://gitlab.com/psi29a/
- Contact:
Re: Heads up...
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
Re: Heads up...
Well thanks for offering the horsepower!
Now we can figure out how much CO2-equivalent OpenMW consumes each time jobs are triggered
Now we can figure out how much CO2-equivalent OpenMW consumes each time jobs are triggered
- psi29a
- Posts: 5361
- Joined: 29 Sep 2011, 10:13
- Location: Belgium
- Gitlab profile: https://gitlab.com/psi29a/
- Contact:
Re: Heads up...
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.
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.
- AnyOldName3
- Posts: 2676
- Joined: 26 Nov 2015, 03:25
Re: Heads up...
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.
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.
- psi29a
- Posts: 5361
- Joined: 29 Sep 2011, 10:13
- Location: Belgium
- Gitlab profile: https://gitlab.com/psi29a/
- Contact:
Re: Heads up...
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:
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- download "Qt 5.7.2" \
"https://download.qt.io/official_release ... -5.7.0.exe" \
+ download "Qt 5.7.0" \
"https://download.qt.io/archive/qt/5.7/5 ... -5.7.0.exe" \
- AnyOldName3
- Posts: 2676
- Joined: 26 Nov 2015, 03:25
Re: Heads up...
They must have changed that in the last week or two, as it was still up when I was updating the documentation.