Ralf Wildenhues wrote:
Thanks for reporting this. Your patch is not quite correct, as it
causes the $ in the libobj name to be quoted twice. Thus, the output
name of the .lo file will be wrong.
Hm. Yes.
Before delving into a better patch: Beware that such file names do not
play too well with other tools, notably make and Automake.
(I guess you knew that, but I thought it necessary to mention anyway.)
Yes, but we don't have a choice, at least for .class files.
If you compile .class files one-by-one (not using the multiple-input-file
support), you'd probably also want $-support for output files, though that's
not an issue for me.
Also note that gcj allows multiple input files compiled to a single
.s or .o file: Thus a useful way to compile a bunch of class files is:
gcj -c *.class -o package.o
As I am quite unexperienced with gcj and java in general: What
consequences with respect to exported symbols/linking does this have?
None. It's roughly equivalent to concatenating the input files.
It's not quite the same, of course. (A C analogy would segregating
static symbols in per-file scopes.) The jc1 compiler is only run once
and only a single .s file is generated.
or with libool:
libtool --mode=compile gcj *.class -o package.lo
It appears that func_mode_compile sets srcfile to the *last*
source file; setting it to the first source file might be better.
However, that's not a priority since the multi-source-file mode
does require specifying -o.
So, does the line fail? What happens and what should happen?
It works with my patch. Without it, it fails if the last filename
in '*.class' contains a $ - which happens in my application.
Note that
at the moment, this kind of use is not supported by libtool. We might
consider adding support for this if there is a good reason for doing so.
Well, it seems to work, with my patch to quote-escape $srcfile.
I don't think I need to "support" beyond that.
What benefit does multi-source-file mode have?
Most obviously it speeds up compilation substantially. Java classes
tend to have a lot of inter-module dependencies, so compiling a single
file will requiring reading, parsing, and analysing a lot of other files.
So essentially you can compile multiple related input files almost as
fast as compiling a single file.
There are also optimization advantages: Compiling multiple input files
generating a single .s file allows the compile to share literals, for
example, or use module-local references.
There is also a "make"-related issue: Compiling Foo.java can create
multiple .class files: Not just Foo.class, but also extra classes for
"non-public" classes, as well as inner/anonymous classes. The latter
have generated names that may look like Foo$inner.class.
You could manually write in your makefile:
Foo.class Foo$inner.class NonPublic.class: Foo.java
$(JAVAC) Foo.java
but this is obviously a maintainance nightmare.
Worse is linking:
library.so: Foo.class Foo$inner.class NonPublic.class
$(LINK) -o library.so Foo.class Foo$inner.class NonPublic.class
So I avoid these problems:
JAVA_SOURCES = Foo.java ...
classes.stamp: $(JAVA_SOURCES)
$(JAVAC) $(JAVA_SOURCES)
touch classes.stamp
library.so: classes.stamp
$(LINK) -o library.so *.class
I'm simpifying a bit, because with gcj you have a choice of
.java->.class->.o or .java->.o directly. However, in Kawa
I'm generating class-files (from Scheme) so I have to be able
to use libtool with .class files.
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
