[+cc bug#9088] On 05/08/2013 12:08 PM, Michael Zucchi wrote: > > Hi list, > > I recently added a tiny bit of java+jni to an auto* configured project, > and during the process came across some discussion from about two years > ago about improving Java support. As documented on: > > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9088 > I'm adding that in CC:, so that this new discussion will get correctly registered in the bug tracker.
> So, it seems the JAVA deprecation was carried out, > Actually, not really. But I see the documentation mistakenly report such a deprecation in pretty strong terms. The attached patch fixes that (and adds you to the THANKS file). > but not the JARS > implementation. I presume that was mainly due to lack of interest > together with critical-path personnel constraints? > Basically, yes. If somebody knowledgeable enough were to write patches, they would likely be gladly received. Of course, there is not need to present complete patches right away; the best thing to do is start with some RFC version to spark a discussion, and then refine/extended them as needed --- and this is where the community should provide help and feedback to the patch writer. > Unfortunately as > much as ant (really) sucks, I can't see the Java world changing it's use > of horrid tools, and the GNU world still seems to shun Java too - so > interest may never pick up. > > However, assuming it hasn't gone anywhere beyond that bug report, > It hasn't, sadly. > where > would one begin were one to try to tackle this? m4 mostly just gives me > the willies so i'm not sure I can help much but if I waste my time it's > only my time wasted. > m4 is only required in order to write configure tests. For this new feature, doing that might be trivial, and needn't be done right away: you could just write the first version of the patches assuming java and jar are present, and follow-up patches might improve on that writing proper configure tests. The real workhorses here are the automake script (~ 8000 lines of perl), and the *.am Makefile fragments in the 'lib/am' subdirectory. That's what you'll need to interact with. So, if you are willing to go ahead, you might want to clone the Automake git repository, read the HACKING file, and start perusing the files 'bin/automake.in' and 'lib/am/*.am' for "inspiration". Also, notice that in order to have any non-trivial change integrated in the official Automake repository, you'll need to either assign copyright for the change to the Free Software Foundation, or at least explicitly put it in the public domain. If you are willing to proceed, contact me off-list, and I'll try to help about this issue. Thanks, and best regards, Stefano
>From 4ccf9a8034c597f33ce9592f06533e3cd096fd99 Mon Sep 17 00:00:00 2001 Message-Id: <4ccf9a8034c597f33ce9592f06533e3cd096fd99.1368124506.git.stefano.lattar...@gmail.com> From: Stefano Lattarini <stefano.lattar...@gmail.com> Date: Thu, 9 May 2013 20:23:40 +0200 Subject: [PATCH] docs: we still don't have the promised better Java interface Reported by Michael Zucchi: <http://lists.gnu.org/archive/html/automake/2013-05/threads.html> See also automake bug#9088. * doc/automake.texi (Java): Adjust and clarify. * THANKS: Update. Reported-by: Michael Zucchi <not...@gmail.com> Signed-off-by: Stefano Lattarini <stefano.lattar...@gmail.com> --- THANKS | 1 + doc/automake.texi | 8 ++++---- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/THANKS b/THANKS index fd023e2..66b3270 100644 --- a/THANKS +++ b/THANKS @@ -261,6 +261,7 @@ Michael Brantley michael-brant...@deshaw.com Michael Daniels mdani...@rim.com Michael Hofmann mho...@googlemail.com Michael Ploujnikov plo...@gmail.com +Michael Zucchi not...@gmail.com Michel de Ruiter mdrui...@cs.vu.nl Mike Castle dalg...@ix.netcom.com Mike Frysinger vap...@gentoo.org diff --git a/doc/automake.texi b/doc/automake.texi index e52cc3a..58561ed 100644 --- a/doc/automake.texi +++ b/doc/automake.texi @@ -7598,11 +7598,11 @@ libtool, The Libtool Manual}) with the @code{LTLIBRARIES} primary. Automake provides some minimal support for Java bytecode compilation with the @code{JAVA} primary (in addition to the support for compiling Java to native machine code; @pxref{Java Support with gcj}). Note however that -@emph{the interface and most features described here are deprecated}; the -next automake release will strive to provide a better and cleaner +@emph{the interface and most features described here are deprecated}. +Future Automake releases will strive to provide a better and cleaner interface, which however @emph{won't be backward-compatible}; the present -interface will probably be removed altogether in future automake releases -(1.13 or later), so don't use it in new code. +interface will probably be removed altogether some time after the +introduction of the new interface (if that ever materializes). Any @file{.java} files listed in a @code{_JAVA} variable will be compiled with @code{JAVAC} at build time. By default, @file{.java} -- 1.8.3.rc0.19.g7e6a0cc
