[Mac] Upgrade Protobuild, Allow MacOS to target newer Xamarin APIs, etc. #4282
Conversation
|
I'm getting this error on the Windows 10 build machine: I've no idea what's causing this, but I'm just going to try a bunch of random stuff to see if I can fix it. |
|
I've just disabled the Windows 10 build in the latest push as a temporary measure so I can test the other platforms. |
|
I just managed to build the WindowsUniversal platform in Visual Studio 2015 on my laptop, so this is definitely a MonoGame build server issue. |
|
I'm almost entirely sure this is because the Windows Universal Platform is pulling down NuGet dependencies, and for some reason the build server doesn't want to reference the right ones. The reason it builds in Visual Studio 2015 is because of I'm going to try and fix this... |
|
Looks like the normal Windows (not Windows 10) build machine needs VS2015 installed as well: and: |
|
Well not necessarily Visual Studio 2015, but it does need MSBuild 14.0 (which can be installed separately if you're worried about any conflicts that VS2015 might introduce). |
|
I'm at a loss for the cause of the Windows 10 Universal app build errors since it's working on my laptop. When I build outside Visual Studio I do get a compilation error (a different error though) at the command line but I don't know why... :/ |
|
Now I'm running into: for the Windows 8 platform. I believe this is #2402, but I don't know why we're only encountering it now? |
Why do we suddenly need VS2015 on the Windows build machine? What changed in this PR to do that? |
|
There's a few things that could have changed it:
We did change the default build toolset to 14.0, the default framework to 4.5 and the default C# version to 6, but that was a month ago (https://github.com/hach-que/Protobuild/issues/119) and Protobuild has been updated in the MonoGame repository since then. Anyway, you don't need VS2015, just the newer MSBuild: https://www.microsoft.com/en-us/download/details.aspx?id=48159 |
|
Replying to my previous post, I think it's the deletion of the XSLTs that's causing this toolset change to occur now. |
|
:D Windows 10 is building successfully.... Now to just address the ToolsetVersion stuff |
We should be looking at the difference in the project generated by the built in Protobuild XSLT and a project generated by VS2015. If Protobuild is generating something different than what VS2015 generates then the bug is in Protobuild itself. If Protobuild is generating the same as VS2015 then our old XSLTs were wrong and we need to change the build process. |
|
We have not been able to get an automatic build of MonoGame Win8 on Windows 8 via VS2012-level build tools. When I tried to build Monogame in VS2012 it (VS) complained that it was not compatible. Even after upgrading the build mx to Win10 and installing VS2015 we still can not build MG for Win8. From VS2015 on my desktop I can make it build just fine. |
|
For the record. The last time we were able to build MonoGame for Windows 8 on a Win8 box without a desktop environment was July 19th, 2015. Since after that day every build has failed with the same .NET 4.5.1 error. |
|
Maybe you can revert back to an earlier SharpDX? Tom's merge on July 20th was the start of the Win8 build problems in our world: |
|
The MonoGame Windows build server currently builds Windows 8 from a Windows 8.1 Pro machine. We have VS2010, VS2012, and VS2013 express installed on that machine. We have installed the latest Windows 8.1 and Windows Phone 8.1 Kits on the machine. So it is pretty standard from what I can see. |
|
Is there any technical reason to not have at least MSBuild 14 installed? Separately I'm interested to know if there's any technical reason to not be using VS2015 given that it's now free. Protobuild's latest templates assume MSBuild 14.0 is installed because it's freely available and is automatically installed with VS2015 (which I assume the majority of people are now using because it's basically free Professional). I do intend on changing this to detect the latest MSBuild that's installed (that's what I'm working on now), but I want to be aware if there's any platforms that have an upper bound on the MSBuild version that I'm not already aware of. |
|
Console SDKs don't always integrate with latest Visual Studio. Except for
Microsoft, they're usually a version or two behind.
|
No.
No. The intent is to move to a new Windows 10 build box where all Windows builds will occur. Till that time we're not going to be changing the build server around when we don't need to.
MonoGame assumes that you can still build using older versions of VS like it has in the past. We don't require everyone install VS2015 just because it is out unless the platform they are targeting requires it.
You need to define what you mean by upper bound. What we don't want is to require someone that has been building MonoGame for Windows 8 on VS2012 for years now to suddenly need VS2015 installed for no good reason. |
As in public (non-NDA) SDKs that do not work under MSBuild 14.0 / VS2015. I expect these to be things like Windows Phone 7 which Microsoft might have dropped support for. Basically I'm going to replace this entire logic that's currently in the XSLT: <xsl:choose>
<xsl:when test="$root/Input/Generation/Platform = 'WindowsUniversal'">
<xsl:text>14.0</xsl:text>
</xsl:when>
<xsl:when test="$root/Input/Generation/Platform = 'WindowsPhone81' or $root/Input/Generation/Platform = 'Windows8'">
<xsl:text>12.0</xsl:text>
</xsl:when>
<xsl:when test="$root/Input/Generation/Platform = 'PCL' or user:IsTrue($root/Input/Properties/ForcePCL)">
<xsl:text>14.0</xsl:text>
</xsl:when>
<xsl:when test="$root/Input/Generation/Platform = 'Windows' or
$root/Input/Generation/Platform = 'MacOS' or
$root/Input/Generation/Platform = 'Linux'">
<!--
We have to choose the ToolsVersion based on the framework, since .NET 4.5
and later use a ToolsVersion that aligns with Visual Studio's version.
-->
<xsl:choose>
<xsl:when test="$__FrameworkVersion = 'v4.0'">
<xsl:text>4.0</xsl:text>
</xsl:when>
<xsl:when test="$root/Input/Generation/HostPlatform = 'Linux' or $root/Input/Generation/HostPlatform = 'MacOS'">
<!--
xbuild and mdtool do not support 14.0 yet, but their C# compiler
supports language level 6, even on older build tools (on Windows
you must be using MSBuild 14.0 to target C# 6).
-->
<xsl:text>12.0</xsl:text>
</xsl:when>
<xsl:otherwise>
<xsl:text>14.0</xsl:text>
</xsl:otherwise>
</xsl:choose>
</xsl:when>
<xsl:otherwise>
<xsl:text>14.0</xsl:text>
</xsl:otherwise>
</xsl:choose>with one that is roughly based on what --build does: https://github.com/hach-que/Protobuild/blob/master/Protobuild.Internal/CommandLine/BuildCommand.cs#L35 That is, it detects the latest MSBuild installed on the machine and sets the ToolsVersion to that. What I need to know is if there were any platforms that had support in VS2013, but are no longer supported in VS2015 (because in that case I need to make the logic prefer the lower version, even if a later one is installed). |
I can't say for sure if that won't cause more problems or not. I highly recommend we stick to what has worked for MonoGame for the last few years. |
|
I want to avoid artificially limiting the tool set version if the user has a later version that will work, because Visual Studio will trigger upgrade dialogs otherwise. |
Yeah... that does suck at times, but a minor concern. At best Protobuild could see that the toolset version MonoGame wants doesn't exist on the system, kick out a warning to the user, and automatically pick the next higher version that does exist and hope for the best. We don't want it just picking the highest or forcing VS2015 in all cases. |
Yeah the newer version of Protobuild won't do that; it will pick the latest version of MSBuild that is installed, unless the platform target doesn't support it in which case it will pick a lower version. Right now it's always picking MSBuild 14 since there was the assumption that everyone had it installed, but that doesn't work if it's not installed (it drops down to 4.0 instead of 12 which breaks things). |
|
Okay so the reason for the Windows 8 failures is this commit: 54bd166 That change shouldn't have been made there, instead the project definitions should have changed the default target framework using https://protobuild.readthedocs.org/en/latest/project_properties.html#frameworkversions |
|
@tomspilman as mentioned the Mac Changes are OK.. my only concern is the removal of the GamePad unless we are compiling for LEGACY (i.e MonoMac). https://github.com/mono/MonoGame/pull/4282/files#diff-ddd2a95bb8ef8bdf191e355bd57cdef3R14 My guess is the API OpenTK was using to access the hardware (HID) is not available in the new unified API. Not sure if its something apple or xamarin removed though.. Apple did introduce a new GCController api for game controllers (see the tvOS port) which makes me suspect apple removed the api.. But that only works for supported devices and currently none of the Mac Xbox 360 controller drivers work with the new API (yet). So not entirely sure how we solve this one moving forward as I'm sure like me all fair chunk of people will Mac's use the 360 controller. |
The gamepad still works for MonoMac and XamMac. It's only the Unified Xamarin.Mac API that doesn't support GamePad, and previously that API wasn't supported at all by MonoGame. The MacOS binaries and packages the build server is producing are still targeting XamMac, so any pre-built binaries people consume will still have GamePad support. |
|
Seems like doing something like saying: With a link back to some page in your docs explaining the details... which seems smart for like 2015. |
|
we thats all right then :) On 17 December 2015 at 09:01, June Rhodes notifications@github.com wrote:
|
Hah... I think until we get the whole GamePad thing worked out we can wait. Two different builds for Mac seems crazy to me... but technically we do have like 4 different projects all targeting Windows in slightly different ways. Still with still under 6% of the desktop OS marketshare... seems a lot of effort for little old Mac. So @dellis1972 ... do I merge this then? |
|
@KonajuGames - I'll let you do the last lookover and merge... I need some sleep. :) |
|
@tomspilman yep thumbs up from me. On 17 December 2015 at 09:09, Tom Spilman notifications@github.com wrote:
|
|
I think a better long term solution is to rip the logic out of OpenTK.Input namespace and put it in it's own DLL for the Unified Mac API or just import it the code into MonoGame when under the Unified API. Because we're on a desktop platform, P/Invoke is still supported, it's just that the OpenTK that Xamarin is shipping in the new API doesn't have the C# namespace, not that the native APIs aren't supported (at least I think this is a strong assumption).
I prefer not to do this because documentation changes or goes out of date, and it requires you to be online to find out the details of the warning. Better to just include all the information given that this is a warning that will appear for TeamCity builds and almost certainly nowhere else (and if it does appear somewhere else for someone else, then it's probably a very important warning to pay attention to). |
I also don't want to add another MacOS platform on the Protobuild level, especially given that fundamentally these are API versioning differences, not actually different platforms. |
hach-que
force-pushed
the
mac-upgrade
branch
3 times, most recently
from
cdf8d3e
to
3d4c0b7
Compare
hach-que
force-pushed
the
mac-upgrade
branch
from
3d4c0b7
to
791b74d
Compare
|
I've updated Protobuild here so it now supports the feature set restriction behaviour I detailed above. With this you won't see changes in behaviour until you opt into them. |
|
What does this big "Merge" button do... |
[Mac] Upgrade Protobuild, Allow MacOS to target newer Xamarin APIs, etc.
|
Darn it, I was looking forward to a nice quite Christmas 🎅 |
|
This broke Pipeline Tool for Linux. #4243 added LocalCopy and set it to false. It needs to be set to false so that we can use GAC gtk-sharp3 stuff. |
|
Submit your changes to the XSLT as a PR to Protobuild upstream (the LocalCopy support), then we can update Protobuild here. |
|
(Even though I don't know why you don't just use |
Linux stuff is compiled from both Windows and Mac. Gtk 3 on Windows has a lot of conflicts with Gtk 2. For Gtk 3 on Mac you would have to compile from source. Also Gtk 3 and 2 on Mac at the same time would cause problems(Mac Pipeline uses gtk 2) with your reference tag since you can't specify the version of the package. |
|
@hach-que Can you fix it, I have no idea where it's supposed to go inside your repository? |
|
The standard XSLT files are under Protobuild.Internal\BuildResources. On Sun, Dec 20, 2015, 01:42 Harry notifications@github.com wrote:
|
I noticed. I tried adding the change from: https://github.com/mono/MonoGame/pull/4243/files to: but the resulting Protobuild.exe didn't turn off LocalCopy. |
|
You need to run On Sun, Dec 20, 2015, 01:52 Harry notifications@github.com wrote:
|
This PR addresses multiple issues at once because they're all dependent on one another:
PLATFORM_MACOS_LEGACYdefine. This resolves [Mac] Upgrade to the newer Xamarin.Mac API #4275, but should also fix bugs like Could not load file or assembly ‘MonoMac’ or one of its dependencies Mac OS X #4278.