Monogame: Remove/Change MonoKickstart
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?
tomspilman
All 15 comments
I vote to remove it.
harry-cpp
on 30 May 2016
Me too, it can live on its own and is there only as an option for packaging DesktopGL projects. Nothing refers to it.
mrhelmut
on 30 May 2016
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.
tomspilman
on 30 May 2016
I need to take some time to complete #4430
I think I'll do this once the OpenTK removal is merged.
mrhelmut
on 30 May 2016
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 :)
harry-cpp
on 21 Feb 2018
@dellis1972 @mrhelmut @cra0zy - So is this issue done? Is it critical we fix this now or can it wait?
tomspilman
on 21 Feb 2018
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.
harry-cpp
on 21 Feb 2018
@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.
dellis1972
on 21 Feb 2018
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
harry-cpp
on 21 Feb 2018
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
dellis1972
on 21 Feb 2018
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.
harry-cpp
on 21 Feb 2018
There's gonna have to be some transition period, can't make the switch without a couple uglies :p
Jjagg
on 21 Feb 2018
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 notifications@github.com 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
https://github.com/MonoGame/MonoGame/issues/4895#issuecomment-367302037,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAxeeTuoek88CMQ9PO7_k2da3F2RKf9sks5tXALPgaJpZM4Ip-FB
.
dellis1972
on 21 Feb 2018
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
on 21 Feb 2018
Kickstart submodule has been removed in: #6213
harry-cpp
on 3 Mar 2018
Related issues
monsieurmax
·
5Comments
Jjagg
·
5Comments
harry-cpp
·
5Comments
Halofreak1990
·
4Comments
MichaelDePiazzi
·
4Comments
Most helpful comment
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 :)