|
Re: How do you export a standalone SWT executable? [message #462616 is a reply to message #462613] |
Sat, 15 October 2005 01:02 |
Daniel Spiewak Messages: 263 Registered: July 2009 |
Senior Member |
|
|
Really the only thing that's changed about the native library handling in 3.1 is that now SWT has everything bundled in a single jar file in the eclipse/plugins directory (i.e. org.eclipse.swt.gtk_3.1.0.jar). The internal structure of the JAR is identical to the structure of the old org.eclipse.swt.gtk_3.0.0 directory (or whatever ws you care to insert). You'll obviously have to extract the native libs from the jar before you can rebundle them in whatever manner you choose.
Oh, as for standalone SWT applications, there are a few techniques for doing it, none of them pretty. The most 'Java' solution is to bundle the native libs with the JAR and then extract them on startup. Unfortunately, you then have to spawn a new VM manually with the java.library.path set properly. (there is a class library to do this for you at http://www.moioli.net/art29.html) On mac, it's possible to export an SWT project (or rather, runtime configuration) to a native application from within Eclipse. But only a macintosh native app. I use Install4J when I can, but like all installers with any features, it can get expensive. Still, it's worth it. Your final option is to use gcj to natively compile your application, statically linking both the jars and the binaries. There are quite a few tutorials on how to do this for each platform, especially with SWT. Unfortunately, gcj is less than perfect and if you're trying to do anything less than straight-forward in your app, you'll probably have trouble. So, all in all, your options are pretty poor.
Oh, there's always Excelsior (named after the starship I'm sure) as far as a native compiler. That works pretty well. But for the moment, it's Windows only, and so is the result.
|
|
|
|
Powered by
FUDForum. Page generated in 0.03871 seconds