********************* ** 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. Export to the filesystem AppleCommander/src/com directory tree into the build directory. 2. 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... 3. Place a copy of the AppleCommander JAR file in the build directory - name it AppleCommander.jar. 4. Copy swt.jar, libswt.a, and swt-win32-*.dll into the build directory. (Check at http://www.thisiscool.com/gcc_mingw.htm and grab a copy.) 5. Ensure that UPX is on the path. You will need to set this manually. I placed UPX in C:\UPX - so I use the following command: export PATH=$PATH:/c/UPX 5. Run build-applecommander-mingw script from MinGW in the build directory. 6. Distribution consists of smallest executable plus the SWT DLL file. ************************* ** 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/attached 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.