improving the build system

[gblues]

I recently documented my pain in building OpenMW on Windows.

I'm wondering--is there any interest in improving the build system?

Problems I ran into:

- CMake does a bad job of finding things, even with environment variables set.
- Some of the CMake scripts assume path hierarchies that are incorrect
- CMake will fail to notice when important dependencies are missing, i.e. it will happily build the OpenMW OSG fork with no FFMPEG.

I work in a Java shop and so we use gradle, maven, and artifactory to manage dependencies. Has anyone explored putting something like that together for OpenMW?

[psi29a]

There have been a lot of recent updates to our cmake code to simplify things and do it 'the right way'.

Obviously there are going to be platform specific code in there, so we could try to improve cmake's detection of libraries which should help make that less painful.

[AnyOldName3]

While it can be wasteful if you've already got things like boost set up for other projects, Ace's script 'just works', so it might be an idea to put a link to it in the build guide on the wiki.

[maqifrnswa]

That's a problem with windows build systems in general. Windows is designed (in my opinion) to make things easiest for users while restricting it as a developer platform. This is especially true for cross-platform projects. cmake (what openmw uses) is probably the best tool for crossplatform builds - but maybe we can do better...

Has anyone tried Ubuntu shell on windows 10 yet? That might be very interesting, and easy. I think that the user-space is the same as linux, so windows can just follow the linux instructions, and it might just work. If it works, maybe we can make that the suggested windows build method?
https://msdn.microsoft.com/en-us/commandline/wsl/about

Also, what about vagrant to help users set up uniform build environments?
https://www.vagrantup.com/

Maybe container builds are a way to try to get the best of both worlds (stable system, uniform build environments). Ubuntu's trying it with "snappy" containers, Android does it with their apps, windows has docker containers on windows server/azure cloud. Maybe keeping an eye on container builds could help in the future too.

[AnyOldName3]

The problem with relying on the new Linux kernel stuff being added to NT is that if you do a build with it, you'll get a linux build, not a Windows build.It basically gives Windows the ability to execute ELF files, like Wine does for EXEs, but at a lower level. Just like how if you were to run Visual Studio through Wine you'd get a Windows build, if you run GCC through this new system, you'd get an Ubuntu build, and when running it, would probably have to suffer whatever performance penalties that incurred.

[psi29a]

That is not how that works... absolutely no linux kernel stuff is going into windows 10.

ubuntu's userland on windows 10 allows you to build applications that run _only_ on windows.

This is just like running debian's userland on freebsd kernel or gnu hurd's kernel. Those applications will only work on the that platform.

Wine doesn't even come close to what is happening here.

The Ubuntu userland are applications that are compiled to run on windows to give the user/developer tools that work just like do on Ubuntu. This choice was made to help lure developers away from OSX and Linux to Windows.

[AnyOldName3]

That's how Cygwin works, but this new stuff does literally run the same ELF files as you'd have on an Ubuntu machine. I could install it right now, then add the OpenMW PPA to it and attempt to apt-get openmw. it'd fail due to unmet dependencies (probably) or maybe just at runtime, as there's absolutely no support for anything other than console applications and file system access at this point, but if I could think of another thing that couldn't possibly have been recompiled for Windows yet, I could have used it as an example.

I tried looking for an actual microsoft site which said this explicitly, but they've only done so in the 17-minute video on this page: https://msdn.microsoft.com/en-us/commandline/wsl/about
If you're happy trusting a third party, How To Geek say this, too in their setup instructions: http://www.howtogeek.com/249966/how-to- ... indows-10/

[aesylwinn]

That's pretty cool. If it's reinterpreting system calls though, I don't imagine OpenGL or windowing systems will be functional anytime soon. Also, I don't think this system would make building windows binaries any easier, unless your going to cross-compile to windows from the integrated Linux . The packaging system with native system libraries is part of what makes it easier develop on Linux in my opinion. I don't understand how what they're doing is any better than Cygwin.

Anyway, I'm not an expert on the matter.

This choice was made to help lure developers away from OSX and Linux to Windows.

I think they'll find that ship has sailed.

[AnyOldName3]

It's not really reinterpreting system calls, as instead of being a usermode program mapping them to different system calls for the host OS, like Wine does, it's the NT kernel directly fulfilling the calls, so the only overhead is that it wasn't originally designed to, so some stuff may happen in a somewhat convoluted way. It potentially means that at some point in the future, OpenGL calls can be passed directly to the existing graphics driver - unlike when running DX software under Wine, no translation needs to occur, and it's not a VM, but the 'same' OS, so isolation doesn't need to be enforced. I've also heard claims that some people have got a X server running in it and have therefore got some GUI applications to work, but I've not looked into that in any detail at all, so it might not be as impressive as it sounds.

[aesylwinn]

Around 14:10 in the video you linked, one of them says, "we are taking all the sys-calls and redirecting them in a way that the Linux windows kernel can understand."

Too be honest, after watching the video I got the impression that it was a lower level vm that had access to the same file system as windows.