search

philcali / sbt-lwjgl-plugin

An sbt / lwjgl plugin
MIT License
44 stars 12 forks source link

LWJGL project executable #5

Closed philcali closed 13 years ago

philcali commented 13 years ago

This would be a really neat feature. I'm exploring the best approach to take with this ...

Saving it for 2.0.6.

-- Philip Cali

philcali commented 13 years ago

Playing around with old school binary building ... Problem with using assembly or protobuf is the jni libs that lwjgl requries... ugh.

I am completely open to suggestions on this matter. I am certainly no expert when it comes to this.

Current implementation here.

philcali commented 13 years ago

I'm leaning more towards an assembly solution as it makes the final product one massive executable jar. I have an idea I want to pursue later on that

A spark went off in my head with integrating conscript with the app (might solve the jni libs and make a single executable).

We'll see.

-- Philip Cali

scan commented 13 years ago

I would somehow advise using ProGuard here, maybe add it to the standard LWJGL-Project? Many Scala project use it to shrink the size and dismiss any not-used libs. Otherwise they'd have to carry about all of the Scala standard lib, though actual project only use a fraction of it.

philcali commented 13 years ago

Yeah... earlier I said protobuf, when in fact I meant proguard. It's been a while since I tried to use it. From what I remember, a proguard configuration felt more project specific (which is understandable), rather than a one size fits all.

You're right about loading too much for most projects. What I would like, is something like conscript which turns your projects into an executable, but uses sbt to launch you app under the covers.

I'm starting to feel like proguard, assembly, and conscript all accomplish the same thing, but exists as sbt plugins to mix in your project configuration.

This plugin might be trailing into the grounds of trying to do too much.

What are your thoughts about this? Do you think that this plugin should create executable binaries, or should we refer developers interested in making executables to one of the existing plugins that do it already?

-- Philip Cali

scan commented 13 years ago

No, the plugin should not create binaries, that goes beyond the sense of it. If people want a binary, they can do it themselves, we should only make it easier to them. And keep in mind, many developers already have a preferred way of doing that and would be maybe not happy to have one way put onto them. And most people would want it to keep a JVM-Version of it anyway.

philcali commented 13 years ago

Agreed. I originally thought that it would be a good idea, but the more dirt I uncovered, the more I realized that it was wrong for this plugin to make that choice. There's some many different ways to make an executable binary, that any way we chose would be "wrong."

I'll make a wiki page offering developers suggestions, and make it clear why this plugin will not create executables for them.

I'm also going to replace this make-exec task with one that simply bombs that lwjgl natives to a folder in the defined target directory. This would save the developer a few commands.

Thanks you for input!

-- Philip Cali