On Thu, May 17, 2018 at 10:27:18PM -0400, James McCoy wrote:
> The biggest wrinkle is that "javac -h" _only_ generates a header file if
> there are native annotations, whereas "javah" would always generate a
> header file. This found some places where we didn't have native
> annotations even though they were needed.
>
> It also throws a wrench in our dependency tracking. We can't just say
> "Hey make, these .java files all generate a .h file, and libsvnjavahl
> depends on all the .h files" anymore.
>
> I was initially going to drop the javah type from build.conf. Since it
> looks like we'll need to explicitly list the header files we expect to
> generate, it will probably be cleaner to use the package-based javah
> stanzas instead. That will also keep the dependencies more accurate.
I've finally cleaned things up and the attached patch works (for me) on
Linux. gen_base.py now has one TargetJava class (based mainly on the
old TargetJavaHeaders), which describes how to generate the .class and
optionally .h files.
Since javac only produces header files when the .java file has native
code, build.conf now lists all such files in a "native" attribute to
avoid unsatisfiable dependencies.
I know there is still work to be done for Windows, and I'll need some
help with that. As I mentioned above, multiple files are generated per
javac command, which our current ezt templates for VisualStudio don't
seem to support. From some brief searching, the solution files do
appear to handle this, but it's not something I can readily test.
I haven't committed to trunk since I didn't want to break the Windows
builds. I'm open to suggestions on how to move forward.
Cheers,
--
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Received on 2018-07-10 06:32:33 CEST