AppleCommander/NATIVE-COMPILE
Robert Greene 391c80dfb8 Updated to more accurately reflect current state of native compiles.
Windows seems to be mostly ok (finally!).
2003-03-27 05:36:39 +00:00

68 lines
3.5 KiB
Plaintext

*********************
** LINUX **
*********************
See build/build-applecommander-linux-gtk for the script which builds
an executable of AppleCommander. The build/build-swt-linux-gtk script
builds the SWT swt.so file.
**********************
** WINDOWS **
**********************
Building AppleCommander for Windows using MinGW (2.0.3 with GCJ update to 3.3).
See build/build-applecommander-mingw for the current script.
1. Using MinGW, date related support classes are not compiled in. This is a known
issue and there is a suggested work-around posted here:
http://gcc.gnu.org/ml/java/2002-04/msg00180.html
Basically, force a reference to the classes which cause the error - the problem
lies in classes loaded by reflection, so this forces these classes to be
compiled in. The suggested prelude is:
// static references to these classes ensure that the linker will include them
private static Class c1 = gnu.java.locale.Calendar.class;
private static Class c2 = java.util.GregorianCalendar.class;
private static Class c3 = gnu.gcj.convert.Input_ASCII.class;
private static Class c4 = gnu.gcj.convert.Input_UTF8.class;
private static Class c5 = gnu.gcj.convert.Input_8859_1.class;
private static Class c6 = gnu.java.locale.LocaleInformation.class;
private static Class c7 = gnu.gcj.convert.Output_ASCII.class;
Presumably, this is just needed in one class - probably the class which contains
the main method. I am currently pasting this into AppleCommander.java itself.
A better solution would be to do this automatically...
*************************
** MISCELLANEOUS NOTES **
*************************
Update #1:
GraphicsFilter was reengineered to accomodate GCJ. GCJ is not quite JDK 1.4 compliant
and is obviously not a SUN JDK. The image creation and saving responsibility was moved
into subclasses of AppleImage. AppleImage itself functions as a factory and tries to
instantiate possible AppleImage classes via Reflection - this allows code to be compiled
without patching the code. When building with GCJ, the AppleImage classes that do not
apply are simply not compiled nor linked into the executable.
Update #2:
Resources can be compiled/atteched to a specific Java class. AppleCommander has
a number of resources that should be built into the exe class. This simplifies
the distribution to be the AppleCommander executable and the SWT support DLL.
See the AppleCommander build script for details.
Update #3:
UPX is a very good compression tool for executables. It should be standard practice
(and part of the automated build process) to run the final EXE and DLL files through
UPX to ensure a small filesize. This has been incorporated into the AppleCommander
build script but you may want to review how it is built in as detection can be funky.
Update #4:
There are speed issues with the compiled version of AppleCommander which appear to
be releated to GCJ 3.2 but do not show up in GCJ 3.3. The speed issues do not
appear to be present when run as a normal Java/SWT application. I am unclear what
the issue was, but the current assumption is that a bug or optimization to GCJ 3.3
was introduced. Additional note - this version of GCJ 3.3 also is packaged with
SWT 2052 which is a few point releases higher than other versions of SWT, so it also
may be SWT releated.