This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Getting gcj to compile what it finds when scanning
Andrew Cowie wrote:
That would make GCJ much more of a drop in replacement for javac, and
THAT would really help drive adoption. I see, again and again, people
trying to use `gcj -C` as an inline replacement for javac in in whatever
context (Makefile, ANT build.xml, whatever) that just ends up making a
mess because its not recursive in the way that javac is.
I go one further, and wish that `gcj -c` was a drop in replacement, more
or less (ok, so we need a custom linking step after. That's the cool
part anyway).
I realize that it's already bad enough with someone else driving the
spec on what we have to implement against, but if they can figure out
which classes need [re]compiling and just get on with it, surely the
foremost compiler in the world can too :)]
It's interesting that this came up on the list now (I just sat down to
catch up so I'll reply here more or less to the whole thread).
I had the same thought about javac and gcj, so I decided to write gme
(gcj made easy). It's written in Java, and compiled with gcj. Here's the
output from gme building itself:
gme -v -o gme -main gcjme.GcjMadeEasy -gcomp "-O3" gcjme
using: /home/tsikes/dev/gcjme
building: 'gcjme'
gcj -c -O3 gcjme/GcjMadeEasy.java -o gcjme/GcjMadeEasy.o
gcj -c -O3 gcjme/CLPException.java -o gcjme/CLPException.o
gcj -c -O3 gcjme/RegExpFileFilter.java -o gcjme/RegExpFileFilter.o
gcj -c -O3 gcjme/GcjmeArgumentParser.java -o gcjme/GcjmeArgumentParser.o
gcj -c -O3 gcjme/Builder.java -o gcjme/Builder.o
gcj -c -O3 gcjme/Exec.java -o gcjme/Exec.o
gcj -o gme --main=gcjme.GcjMadeEasy -O3 gcjme/GcjMadeEasy.o
gcjme/CLPException.o gcjme/RegExpFileFilter.o
gcjme/GcjmeArgumentParser.o gcjme/Builder.o gcjme/Exec.o
gme also knows how to traverse directory heirarchies, so it can already
build multi-package programs (scimark for instance).
I intend to release it under the GPL once it's a little further along.
Here is my current (tentative and subject to change) notes file on it:
---start notes---
gme (gcj made easy)
Front end for gcj written in Java (gcj dialect).
Traverses (current) directory tree, understands classpath.
Builds all .java files in tree.
- Uses .java, .class files in that order.
- Builds shared libraries out of .jar by default.
Ends up with executable and shared libraries in (current) target directory.
Switches:
-c Compile everything, don't link.
-d Do specified single directory only, don't traverse tree.
-f Explicitly specify options file.
-g Build everything with debugging information.
-gcomp String containing options to pass through to each gcj compile
invocation, overrides options file. Also passed to link
invocation.
-glink String containing switches for final link gcj invocation.
-m Mode similar to "make". Only builds out-of-date .o files, as
determined by source and dependency timestamps.
-main Specifies main class for gcj link. If not specified, gcje
searches for main class, reports and exits if multiple.
-o Name for generated executable, defaults to main class name
minus ext. (or main class name plus ".exe" on Win).
-static Results in static executable, if possible.
-shared Results in shared library(ies) only. Each unique package
results in library, unless code is in a .jar.
lib-packagename.so (??? look at gcj .jar/sharelib handling)
-strip Strip final executable.
-v Verbose flag - print informative output during processing.
Examples:
gme .
gme -o foo *.java
gme -main jnt.scimark2.commandline -o sm2 .
gme -o foo ./foopackage
TODOS:
1) Get main class detection working. It'll be interesting to see how
much this slows things down...
2) Get proper dependency detection in for "-m".
3) Hack in .class file compilation.
4) Get .jar=>.so support working.
5) Hack in better classpath support so any other .jar used will compile
into .so format.
6) Do we need a "follow symlinks" flag?
---end notes---
So, any interest? Or silly idea? :-)
Terry