I am just curious if it is possible to maintain a c#-project in the unity-spine git repo fo precompiling a managed-dll Version of the runtime? I would want to keep compile times in Unity low. Also Unity-Packages are a pain.
Thanks,
Benedikt
I am just curious if it is possible to maintain a c#-project in the unity-spine git repo fo precompiling a managed-dll Version of the runtime? I would want to keep compile times in Unity low. Also Unity-Packages are a pain.
Thanks,
Benedikt
We'll look into it this week.
You're welcome to contribute a .csproj yourself too.
Some other users ran into some AOT problems when compiling spine-unity to dll, but it was a matter of adding some attributes.
.unitypackage files are handy for some people but they're not for everyone.
Thanks for letting me know! Sounds great
I had a quick look into it last week before posting. I guess the biggest issue would be the UNITY_EDITOR prepocessor directives, specifically if they are in the non-editor part of the library. as well as dissecting Editor code into a separate spine-unity-editor.dll. Application.IsEditor should help out here, no Idea if there are any performance repercussions for the current code.
For Unity Versioning having the same preprocessors as the engine (like UNITY_5) should help with compatibility, however I guess the library should also be linked against the unity version the user is using. Most of the time it is save to have it build against a different version (been doing this a lot), but sometimes it leads to a startup crash. I have some experience with this for our own code base which I groomed for the last few years, if you are interested in more pointers, let me know!
Was thinking to look more into the code myself, but I am not as versed int the details of your runtimes to dissect the code without breaking editor functionality.
I don't think it's changes that we can do immediately or finish quickly on our end.
Feel free to share any more info. Or if you want to branch the code yourself sooner, we can drop in feedback.
Most instances of #if UNITY_EDITOR
directives in the non-editor assembly are because some components are marked as [ExecuteInEditMode]. Are you familiar with how those are usually resolved (other than using Application.IsEditor)?
In any case, I think it'll have to be up to the user to manage their defines based on their versions, remove unneeded modules and compile their own managed dlls. We definitely won't be building and including a dll as downloadable for any combination of Spine version and Unity version, for these reasons.
I am mid production so I won't have the time to branch immediately as well, but if I find the time before your do I will let you know.
[ExecuteInEditMode] Should be called and executed the same way as in an open script file. I have not used this attribute in actual production code, but if I remember correctly it worked fine last time I tried. Other exotic attributes like [RuntimeInitializeOnLoadMethod] are working as well, so it is a safe bet. If this is the only Editor/Runtime trespass the restructure should work rather swiftly.
Important is not to have any UnityEditor.dll references in the main *.dll since it will break any build.
You are right, versioning should be left to the user for obvious reasons. Having a build project is more than enough.
I don't think using any UnityEditor classes in the main assembly works anyway.
At the very least, I know none of the Spine-Unity code does something weird like that.
I did a quick & Dirty setup last night:
Because some fields in spine-sharp are marked as internal, the whole spine-sharp library would have to be copied over in to spine-unity and could not be used as separate reference. For some or all of these fields might be a public variant present I did not check (quick & dirty as I said)
Removing the UNITY_EDITOR fields was painless. Having the OnDrawGizmo -functions not captured in UNITY_EDITOR should not make a difference to any build, since it would not be called anywhere outside the editor. There where a maximum of 2/3 situations where Application.IsEditor would be really necessary and should do the trick.
I found some platform defines (mainly Windows phone/store related). I did not look into them further, but they might break Multi-Platform support through a single library. There would still be the possibility to have several unity-libraries and marked inside the editor for their distinct platforms, but this is kind of a bad workaround.
Folder-Structure: I messed up your project structure badly in my branch (Again doing a quick test here). I am not sure how you would prefer a data structure that is maintainable especially regarding the spine-sharp library code. Also I would advise having several *.dll Maybe: spine-unity.dll, spine-unityeditor.dll, spine-unityUI.dll, spine-UnityUIEditor.dll, spine-UnityModules.dlll
Unity handles its new UI system as "Extension" inside their code base, maybe having the reference here apart from the main library might give enough flexibility for future restructures on the engine part. Additional unitymodules just sound like a plus for the user (in terms of modularity), but I am not sure how much of a gain or workflow improvement this might be.
Resources/Editor/Shader files would have be kept outside of the library and be packed into an UnityPackage again. Except the raw textdata is stored inside the library and would recreate/overwrite the files at there destination every time the user starts up the editor. This is a possible solution but sounds a bit like a crutch as well.
My compilation did not work inside the Editor. I did get Constructor errors from some Editor Script. I won't have time to investigate here further for now, but if you are interested I can push/you can pull my WIP branch.
*edit: Was this of any help?