Makefile patch: CNI header dependencies

[Bryce McKinlay]

Jeff Sturm wrote:

>Originally nat_headers relied only on this rule, I think:
>
>## This is an evil hack to work around an automake limitation.  We
>## need to ensure that the built headers are built before we try to
>## compile the C++ sources, but we can't make the .o files depend on
>## the headers, because in that case we'll force a complete rebuild of
>## the C++ code whenever any .java file is touched.
>all-recursive: $(nat_headers) $(x_nat_headers)
>
>IIRC this worked OK as long as make was called recursively, but I had
>trouble getting nat_headers to rebuild reliably, so I added the
>dependency on libgcj.jar.
>
>Note that the comment above seems at odds with the behavior you reported.
>

Yes. This rule is, I think, still required in order to make sure all the 
headers get built since our own native files (are supposed to) depend on 
individual .h files and not nat_headers as a whole.

All the dependencies seem to work fine with my patch, except for the 
native files which are in subdirectories ??

ie: if I touch java/lang/UnsatisfiedLinkError.java, which prims.cc 
depends on, the the .class file gets built, gcjh gets run on it, and 
prims.cc gets rebuilt - perfect. But if I touch 
java/net/InetAddress.java, the .class and .h get built fine but it does 
not trigger a rebuild of java/net/natInetAddress.cc.


>>And BTW does anyone know why libtool is now doing the following during
>>make install? its very annoying!
>>
>
>Good question.  Libtool is supposed to relink only on a few platforms
>where it is required.  Is this happening on the trunk only?
>

I think so.

regards

Bryce.