This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]