mirror of
https://github.com/AppleCommander/AppleCommander.git
synced 2024-12-22 23:29:34 +00:00
68 lines
3.5 KiB
Plaintext
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.
|