RoboVM compiler version is tied with plugin

[zainab-ali]

Hi,

Looking through the project it seems as though the robovm compiler is tied to the plugin. Is there any reason for this behavior i.e. RoboVM breaks each minor version change?

If not, it would be great to allow users to be able to change the robovm compiler version downstream.

[Darkyenus]

Yes, the reason for plugin-RoboVM version synchronization is that the RoboVM API (= compiler) sometimes changes and attempting to separate it would be very messy and less stable (we would have to test each minor change to all supported RoboVM versions, which would be time consuming and error prone). Is there any particular reason why you would want it?

[zainab-ali]

I am more worried about bugfixes appearing in the newer versions and not being able to take them, even if the client api is the same (though reading through the code it looks as though we can change the library version).

It seems strange that the api used by the client libraries and the compiler are tied.

[Darkyenus]

If you need newer RoboVM, you can compile and publish it yourself locally before we get to publishing it officially, there is a version1.7 branch for RoboVM 1.7 and I am working on 1.8 at the moment. Just follow the "Hacking on plugin" section in README. If you want newer plugin than RoboVM, you will probably have to backport manually.

I don't know if mixing compiler and RoboVM runtime versions is a wise idea, RoboVM evolves quickly and all sorts of nasty bugs can come out of that.

Anyway, do you have any specific concern/need? Untying plugin version from RoboVM version probably won't happen anytime soon, maybe later when RoboVM stabilizes and only if it makes sense for the users (and us).

[yilinwei]

No we don't have any particular need. The only bugs I can think of being introduced is if the AppCompiler XML/API was significantly different as the robovm bootstrap gets added by the compiler anyway (so it will still be 'compiled' with the same version as the API which you code to).

We've started a fork wip which can do this since I'm also trying to integrate proguard into in properly and nicely with the android plugin we're using heavily.

[Darkyenus]

Adding proguard support should be straightforward, that is what the robovmInputJars key is for. Although since RoboVM is already optimizing and can be configured to minimize the code as well, the returns are not as big as on android. (That is why it is not included by default)

[yilinwei]

Yes I've seen the treeshaker settings. I'm adding it more as tree shaker is disabled on 32 bit machines and the compiler seems to be ridiculously slow on our osx machine.

At any rate, I think this issue can be closed for now.

[Darkyenus]

I don't know about tree shaker not working in 32bit builds, source? I use it without problems to build 32bit apps.

[yilinwei]

Not 32 bit builds, on 32 bit machines. We get an warning message when we run the robovm compiler.

[Darkyenus]

Oh, sorry, missed that. That seems like a RoboVM problem. However, it does explain why are your builds slow, Apple has not been making 32bit machines for quite some time.