Remove/Change MonoKickstart

[tomspilman]

We currently have a submodule for MonoKickstart here:

https://github.com/mono/MonoGame/tree/develop/ThirdParty/Kickstart

It points to this repo...

https://github.com/OutOfOrder/MonoKickstart/tree/5e03d0127e514dcf8a63ae9ebd385cd392dcde52

... and for some reason not our fork...

https://github.com/MonoGame/MonoKickstart

What do we need to do here? Do we update the submodule? Do we remove it?

[harry-cpp]

I vote to remove it.

[mrhelmut]

Me too, it can live on its own and is there only as an option for packaging DesktopGL projects. Nothing refers to it.

[tomspilman]

So then how do people learn about it and which one to use?

I think along with removing it we need to add something to the docs to at least point users in the right direction.

[mrhelmut]

I need to take some time to complete #4430
I think I'll do this once the OpenTK removal is merged.

[harry-cpp]

On a side note, with .NET Core this will be useless since it has a built in command for bundling up the .NET Core runtime :)

[tomspilman]

@dellis1972 @mrhelmut @cra0zy - So is this issue done? Is it critical we fix this now or can it wait?

[harry-cpp]

I would say this can wait. I mean the kickstart works, we just don't have any proper docs on it.

Feel free to leave it in the milestone, in case you do, I'll see to setup a PR for this tomorrow.

[dellis1972]

@cra0zy has .net Core fixed the PInvoke issue? Last time I looked it didn't have the dll.config ability that mono has? I think we still need KickStart about but we can remove the submodule and just document it.

[harry-cpp]

It's kind of fixed, just name the native libs the same way and place them in rid (runtime id, ie. win-64, linux-x64, ie.) folders. Thats what I've been using for the DesktopGL .NET Core nuget package:

<Content Include="..\ThirdParty\DesktopGL\win-x86\libopenal.dll" PackagePath="runtimes\win-x86\native" Visible="false" />
<Content Include="..\ThirdParty\DesktopGL\win-x86\libSDL2-2.dll" PackagePath="runtimes\win-x86\native" Visible="false" />

<Content Include="..\ThirdParty\DesktopGL\win-x64\libopenal.dll" PackagePath="runtimes\win-x64\native" Visible="false" />
<Content Include="..\ThirdParty\DesktopGL\win-x64\libSDL2-2.dll" PackagePath="runtimes\win-x64\native" Visible="false" />

<Content Include="..\ThirdParty\DesktopGL\linux-x86\libopenal.so" PackagePath="runtimes\linux-x86\native" Visible="false" />
<Content Include="..\ThirdParty\DesktopGL\linux-x86\libSDL2-2.so" PackagePath="runtimes\linux-x86\native" Visible="false" />

<Content Include="..\ThirdParty\DesktopGL\linux-x64\libopenal.so" PackagePath="runtimes\linux-x64\native" Visible="false" />
<Content Include="..\ThirdParty\DesktopGL\linux-x64\libSDL2-2.so" PackagePath="runtimes\linux-x64\native" Visible="false" />

<Content Include="..\ThirdParty\DesktopGL\osx\libopenal.dylib" PackagePath="runtimes\osx\native" Visible="false" />
<Content Include="..\ThirdParty\DesktopGL\osx\libSDL2-2.dylib" PackagePath="runtimes\osx\native" Visible="false" />

Alternatively if we need to actually change the native lib names we are calling, we could always write our own function loader: https://github.com/GtkSharp/GtkSharp/blob/develop/Source/Libs/Shared/FuncLoader.cs

[dellis1972]

Hmm ok. So we need any changes in our code to support that? I saw in your fork you altered the dll names we pass about.. We can bring that change in, but we need to make sure we don't break existing people who are just using DesktopGL. We should be able to use the exact same assembly for both .net.mono and .net core

[harry-cpp]

Do you want me to try and submit the PR for .NET Core version of DesktopGL? I mean I could do it, tho we would need a custom .csproj file, plus we would need to multicompile the assembly so that it can be used from lower .NET Framework versions, plus the templates would need to reference the nuget for it instead of using our version of GAC.

[Jjagg]

There's gonna have to be some transition period, can't make the switch without a couple uglies :p

[dellis1972]

I think we have to produce the normal DesktopGL as it is , and a separate .net core one in parallel.. that said I've used the normal DesktopGL with .net core and its fine, the only problem I found so far on Mac are the dylib names which you can hack around for now.

…

On 21 February 2018 at 11:49, Jesse ***@***.***> wrote: There's gonna have to be some transition period, can't make the switch without a couple uglies :p — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4895 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAxeeTuoek88CMQ9PO7_k2da3F2RKf9sks5tXALPgaJpZM4Ip-FB> .

[harry-cpp]

I think we have to produce the normal DesktopGL as it is , and a separate
.net core one in parallel..

Nuget can contain multiple assemblies, ie. it can contain both the .NET Standard and .net framework assemblies inside it.

that said I've used the normal DesktopGL with .net core and its fine, the
only problem I found so far on Mac are the dylib names which you can hack
around for now.

Yea, I've already made PRs for all the changes I had to do to get it running, so pretty much the only things left are the project file and packaging.

[harry-cpp]

Kickstart submodule has been removed in: #6213