Getting gcj to compile what it finds when scanning

Mon Feb 21 22:34:00 GMT 2005

Tom Tromey wrote:
>Andrew> gcj does this if you are having it generate .class files (-C) and you
>Andrew> give it a -d flag
>>Hmm, I thought it didn't do this.
>>
Right, it doesn't. For .class files it is definitely a bug that "gcj -C" 
doesn't recursively generate the dependencies since it behaves 
differently compared to javac etc, and performance is reduced because we 
keep parsing the same .java files over and over.
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. 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.
>Andrew> Is having gcj automatically compile necessary complements
>Andrew> hypothetically possible, or does it violate some ancient
>Andrew> deeply held religious superstition? If it were to be doable, I
>Andrew> don't suppose there is any chance that it might sneak its way
>Andrew> into GCJ-4?
>>I think the problem is that this is something that would have to be
>handled by the gcc driver, say by invoking jc1 and as multiple times.
>I don't think this can be done purely in gcj.
>>
Yeah, it would probably require major changes to GCC's backend machinery 
to allow the front end to generate multiple .o files from one 
invocation. I suppose the driver could call jc1 to get a list of 
dependencies, then invoke it once for each file that it gets back - but 
this would be much slower than a single jc1 invocation, and I think the 
benefits of doing this are questionable.
Regards
Bryce