Re: Getting gcj to compile what it finds when scanning

[Andrew Cowie <andrew at operationaldynamics dot com>]

On Mon, 2005-21-02 at 11:45 -0500, Bryce McKinlay wrote:
> For native compilation its not so clear. It could be useful in some 
> cases, such as static compilation, but there are a lot of caveats. 
> There's no way for the compiler to detect classes that are only loaded 
> dynamically, for example.

Ok, so leave that out of it (although, things like Tomcat and other JSP
engines figure it out dynamically at run time just fine). My point is
mostly that although some very complex programs do runtime class
loading, 

[did I hear that kaffe is [considering] using GCJ as a runtime inline
compiler?]

>  There is also the issue of where to stop - do 
> you include classes seen in jar files, or in libgcj itself? Or will the 
> developer want these classes in shared libraries? Think of generating an 
> executable or .so in gcj as analogous to generating a .jar with the 
> traditional java tools - in most cases its probably better for the 
> developer to keep control of what goes into the final binary.

My thought was that this issue would be avoided if the {recursive
behaviour + plunking individual output files in appropriate -d specified
directories} was limited to gcj invocations with -c, resulting in a tree
being populated with (only) .o files.

Then the developer could, as you say, link up a final binary or shared
library as they see fit.

[perhaps with one further flag to enable the recursive behaviour. But if
we had that, then javac and gcj [-c or -C] would work "the same", ie

	javac -d tmp -classpath src src/fruit/Vendor.java
->
	tmp/fruit/Vendor.class
	tmp/fruit/Watermelon.class
	tmp/fruit/CashTill.class

and 

	gcj -d tmp -classpath src -c src/fruit/Vendor.java
->
	tmp/fruit/Vendor.o
	tmp/fruit/Watermelon.o
	tmp/fruit/CashTill.o


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 :)]

AfC
Sydney

-- 
Andrew Frederick Cowie
Operational Dynamics Consulting Pty Ltd

Operations Consultants and Infrastructure Engineers
specializing in large installation systems administration,
enterprise architecture, and performance improvement for both
the systems and the people who run them

http://www.operationaldynamics.com/