Re: patch to fix missing quoting

[Per Bothner]

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
address@hidden   http://per.bothner.com/