Re: PATCH: Make Makefile.am work in parallel

[Mark Mitchell <mark at codesourcery dot com>]

--On Monday, May 06, 2002 10:27:14 PM -0600 Tom Tromey <tromey@redhat.com> 
wrote:

>>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:
>
> Mark> Or tell the compiler to put the .class files right next to where
> Mark> they want to go and then run "mv" right when you were done.
> Mark> That would be atomic; either the file is there or it ain't.  Can
> Mark> we control where the .class files goes in that way?
>
> Yes, I think all .class files are written via write_classfile() in
> java/jcf-write.c.

Hmm, I was hoping there was already a command-line option so that we
could do this without mucking with the compiler itself.  There's no
option to change the name of the class file, but there is "-d".  So,
we could do, roughly speaking:

  gcj -C -d tmp foo.java
  mv tmp/foo.class foo.class

That would be atomic on all sane systems, I believe, since the two
directories are known to be part of the same file system.  Would a
patch to do that be acceptable?

(I haven't looked at the .class file format in detail in a long time;
is there a file header field that indicates the length of the file?  If
there were, we could just make the compiler ignore files that don't
have the length specified, which might be of general utility to gcj
users.)

> Ultimately it might be fastest for us to parallelize and run one gcj
> invocation per package, or something similar.  Generating multiple
> class files from a single invocation really does help.

I can certainly believe that.  But, the per-package idea would seem to
run into the same problem with munged .class files, unless you know
there are no cross-package imports.

I suppose that even doing them in blocks of N would be an improvement
over the current method, though, and relatively noncontroversial.

The motivation for all this is that building the library takes *forever*;
it took approximately four times as long to build the library as it took
the compiler to bootstrap on the machine I was using.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com