From: Rafael L. <rla...@us...> - 2004-07-11 19:15:34
|
Andrew Ross used to be very responsive in the past and since he did not react to some messages I sent to him these last days, I suppose that he is either on holidays or unavailable. I am attaching below the messages related to the Java binding configuration for PLplot. I noticed some problems, in particular the use of non-portable (GNU make) pattern rules in some Makefile.am's. The patch included below fixes the problems. If nobody objects, I will commit it. I am asking here because my knowledge of Java is quite poor. -- Rafael |
From: Rafael L. <rla...@us...> - 2004-07-13 06:46:06
Attachments:
plplot-java.patch
|
* Alan W. Irwin <ir...@be...> [2004-07-11 15:06]: > On 2004-07-11 21:14+0200 Rafael Laboissiere wrote: > > > (1) I think that the make code for generating the plplot.jar file should be > > in bindings/java/Makefile.am instead of examples/java/Makefile.am. > > > (2) Instead of using install-data-hook for generating plplot.jar, it is > > better to use the automake machinery for that. In particular, it is > > interesting to make plplot.jar depend on $(javaclasses). > > Please don't do (1). Both core and examples should be in the jar file so > that it is self-contained with every aspect (both *.java files and *.class > files) of our interface and examples included (aside from the dynamically > loaded shared object wrapper and the libplplot library it requires.) Oh, I failed to notice that the examples classes were also included in the jar file. Note taken. > The proper way to put both our interface and examples in the jar file is > create the jar file in bindings with jar -c, and append to it in examples > with jar -u, but for the fastjar version of jar, the -u option is disabled. > So to work around this limitation you have to do only one jar -c, and since > examples are treated later than bindings, that is where we chose to do that > one jar -c execution that is available to us. I commented about this > already in examples/java/Makefile.am. > > # Note the java package is actually assembled in the java bindings > directory. > # Fastjar doesn't update packages properly so we need to do it all in one > go. > > Perhaps you may want to rewrite that comment to make it a bit more clear. Yes, the comment is not clear enough and should be rewritten. > I think this jar limitation also means you should not do (2) since probably > the automake machinery is not aware of the limitation in fastjar. > > I see nothing wrong with the rest of your ideas (although I haven't looked > in detail) so I suggest go ahead and make that part of the commit, but I > would avoid (1) and (2) for the reasons I have mentioned. I reworked my solution add propose a new patch, attached below. It addresses all the issues that I mentioned before, but the building of the plplot.jar file is now in examples/java, using a Makefile rule instead of the previous install-hook. In bindings/java, there is now a noinst_DATA target called jar-stamp, which is an empty file, dependent on the *.class files. It is used in examples/java/Makefile.am as a dependency to plplot.jar. As before, this patch eliminates the non-portable pattern rule and created AC_SUBST variables for the java and jar commands. Comments are welcome. -- Rafael |
From: Andrew R. <and...@us...> - 2004-07-13 08:14:58
|
Hi Rafael, The original message never got through to me - I guess it must be sourceforge playing up. I've had a look at these changes and it seems reasonable to me. Your experience with automake is much more than mine. I originally tried something similar but didn't get it to work. Your solution looks neater. Reading the documentation it seems that java support is starting to make it's way into automake, but it's certainly not complete yet and doesn't seem to quite fit our needs. Hopefully this will change in the future. I'm happy for you to submit these changes anyway. Disclaimer: I haven't actually had chance to try them yet. Cheers Andrew On Tue, Jul 13, 2004 at 08:44:56AM +0200, Rafael Laboissiere wrote: > * Alan W. Irwin <ir...@be...> [2004-07-11 15:06]: > > > On 2004-07-11 21:14+0200 Rafael Laboissiere wrote: > > > > > (1) I think that the make code for generating the plplot.jar file should be > > > in bindings/java/Makefile.am instead of examples/java/Makefile.am. > > > > > (2) Instead of using install-data-hook for generating plplot.jar, it is > > > better to use the automake machinery for that. In particular, it is > > > interesting to make plplot.jar depend on $(javaclasses). > > > > Please don't do (1). Both core and examples should be in the jar file so > > that it is self-contained with every aspect (both *.java files and *.class > > files) of our interface and examples included (aside from the dynamically > > loaded shared object wrapper and the libplplot library it requires.) > > Oh, I failed to notice that the examples classes were also included in the > jar file. Note taken. > > > The proper way to put both our interface and examples in the jar file is > > create the jar file in bindings with jar -c, and append to it in examples > > with jar -u, but for the fastjar version of jar, the -u option is disabled. > > So to work around this limitation you have to do only one jar -c, and since > > examples are treated later than bindings, that is where we chose to do that > > one jar -c execution that is available to us. I commented about this > > already in examples/java/Makefile.am. > > > > # Note the java package is actually assembled in the java bindings > > directory. > > # Fastjar doesn't update packages properly so we need to do it all in one > > go. > > > > Perhaps you may want to rewrite that comment to make it a bit more clear. > > Yes, the comment is not clear enough and should be rewritten. > > > I think this jar limitation also means you should not do (2) since probably > > the automake machinery is not aware of the limitation in fastjar. > > > > I see nothing wrong with the rest of your ideas (although I haven't looked > > in detail) so I suggest go ahead and make that part of the commit, but I > > would avoid (1) and (2) for the reasons I have mentioned. > > I reworked my solution add propose a new patch, attached below. It > addresses all the issues that I mentioned before, but the building of the > plplot.jar file is now in examples/java, using a Makefile rule instead of > the previous install-hook. > > In bindings/java, there is now a noinst_DATA target called jar-stamp, which > is an empty file, dependent on the *.class files. It is used in > examples/java/Makefile.am as a dependency to plplot.jar. > > As before, this patch eliminates the non-portable pattern rule and created > AC_SUBST variables for the java and jar commands. > > Comments are welcome. > > -- > Rafael > Index: cf/java.ac > =================================================================== > RCS file: /cvsroot/plplot/plplot/cf/java.ac,v > retrieving revision 1.11 > diff -u -r1.11 java.ac > --- cf/java.ac 7 Jul 2004 08:27:52 -0000 1.11 > +++ cf/java.ac 12 Jul 2004 08:34:50 -0000 > @@ -112,6 +112,23 @@ > AC_MSG_WARN([setting enable_java=no]) > enable_java=no > fi > + > + # Check if Java compiler is present > + AC_CHECK_PROGS(JAVAC, javac, no) > + if test "$JAVAC" = no ; then > + AC_MSG_WARN([javac command not found,]) > + AC_MSG_WARN([setting enable_java=no]) > + enable_java=no > + fi > + > + # Check if jar command is present > + AC_CHECK_PROGS(JAR, jar, no) > + if test "$JAR" = no ; then > + AC_MSG_WARN([jar command not found,]) > + AC_MSG_WARN([setting enable_java=no]) > + enable_java=no > + fi > + > fi > > if test "$enable_java" = yes; then > Index: bindings/java/.cvsignore > =================================================================== > RCS file: /cvsroot/plplot/plplot/bindings/java/.cvsignore,v > retrieving revision 1.6 > diff -u -r1.6 .cvsignore > --- bindings/java/.cvsignore 29 Jun 2004 14:51:15 -0000 1.6 > +++ bindings/java/.cvsignore 12 Jul 2004 08:34:50 -0000 > @@ -13,5 +13,6 @@ > plplotjavac_wrap.c > plplotjavacConstants.java > plplot > -plplot.jar > classnoinst.stamp > +*.class > +jar-stamp > Index: bindings/java/Makefile.am > =================================================================== > RCS file: /cvsroot/plplot/plplot/bindings/java/Makefile.am,v > retrieving revision 1.36 > diff -u -r1.36 Makefile.am > --- bindings/java/Makefile.am 7 Jul 2004 08:27:51 -0000 1.36 > +++ bindings/java/Makefile.am 12 Jul 2004 08:34:50 -0000 > @@ -20,8 +20,6 @@ > # along with the file; if not, write to the Free Software > # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > > -JAVAC = javac > - > SWIG_SUPPORT_DIR = $(top_srcdir)/bindings/swig-support > PLPLOTCAPI_I = $(SWIG_SUPPORT_DIR)/plplotcapi.i > > @@ -48,13 +46,13 @@ > # Note : the order of these is important since there is no formal > # dependency checking. > javaclasses = \ > - plplot/core/config.class \ > - plplot/core/PLStreamc.class \ > - plplot/core/plplotjavacJNI.class \ > - plplot/core/SWIGTYPE_p_p_char.class\ > - plplot/core/plplotjavacConstants.class \ > - plplot/core/plplotjavac.class \ > - plplot/core/PLplot.class > + config.class \ > + PLStreamc.class \ > + plplotjavacJNI.class \ > + SWIGTYPE_p_p_char.class\ > + plplotjavacConstants.class \ > + plplotjavac.class \ > + PLplot.class > > ### FIXME: Brute force inclusion in dist tarball. The files below may > ### be treated in a different way for installation [RL, 2003-03-06] > @@ -97,8 +95,15 @@ > # Can't use java support for now since jikes doesn't handle dependencies > # properly - instead do it using DATA and with an explicit rule. > #noinst_JAVA = $(javafiles) > -#plplotjavadir = $(DATA_DIR)/java/ > -#plplotjava_DATA = plplot.jar > + > +.java.class: > + $(JAVAC) $(AM_JAVACFLAGS) $(JAVACFLAGS) $< -d . -classpath . > + cp plplot/core/$@ . > + > +noinst_DATA = jar-stamp > + > +jar-stamp: $(javaclasses) > + touch jar-stamp > > ourexecjava_DATA = $(javafiles) $(javaclasses) README.javaAPI > > @@ -107,10 +112,9 @@ > # if enable_java > endif > > -plplot/core/%.class : %.java > - $(JAVAC) $(AM_JAVACFLAGS) $(JAVACFLAGS) $< -d . -classpath . > - > clean-local: > rm -rf plplot > > +CLEANFILES = $(javaclasses) jar-stamp > + > MAINTAINERCLEANFILES = $(swiggenfiles) > Index: examples/java/.cvsignore > =================================================================== > RCS file: /cvsroot/plplot/plplot/examples/java/.cvsignore,v > retrieving revision 1.3 > diff -u -r1.3 .cvsignore > --- examples/java/.cvsignore 30 Jun 2004 16:04:53 -0000 1.3 > +++ examples/java/.cvsignore 12 Jul 2004 08:34:50 -0000 > @@ -6,5 +6,7 @@ > .libs > *.la > *.lo > -plplot-examples.jar > +plplot.jar > plplot > +*.class > + > Index: examples/java/Makefile.am > =================================================================== > RCS file: /cvsroot/plplot/plplot/examples/java/Makefile.am,v > retrieving revision 1.14 > diff -u -r1.14 Makefile.am > --- examples/java/Makefile.am 7 Jul 2004 08:27:52 -0000 1.14 > +++ examples/java/Makefile.am 12 Jul 2004 08:34:50 -0000 > @@ -44,30 +44,29 @@ > javademos = README.javademos $(javafiles) Makefile.examples > > # These are for make check compilation of examples. > -JAVAC = javac > PLPLOT_CLASSPATH= `pwd`/$(top_builddir)/bindings/java > > example_classes = \ > - plplot/examples/x01.class \ > - plplot/examples/x02.class \ > - plplot/examples/x03.class \ > - plplot/examples/x04.class \ > - plplot/examples/x05.class \ > - plplot/examples/x06.class \ > - plplot/examples/x07.class \ > - plplot/examples/x08.class \ > - plplot/examples/x09.class \ > - plplot/examples/x10.class \ > - plplot/examples/x11.class \ > - plplot/examples/x12.class \ > - plplot/examples/x13.class \ > - plplot/examples/x14.class \ > - plplot/examples/x15.class \ > - plplot/examples/x16.class \ > - plplot/examples/x17.class \ > - plplot/examples/x18.class \ > - plplot/examples/x19.class \ > - plplot/examples/x22.class > + x01.class \ > + x02.class \ > + x03.class \ > + x04.class \ > + x05.class \ > + x06.class \ > + x07.class \ > + x08.class \ > + x09.class \ > + x10.class \ > + x11.class \ > + x12.class \ > + x13.class \ > + x14.class \ > + x15.class \ > + x16.class \ > + x17.class \ > + x18.class \ > + x19.class \ > + x22.class > > if enable_java > > @@ -79,19 +78,33 @@ > examples_execjavadir = $(datadir)/java/plplot/examples > examples_execjava_DATA = $(javademos) $(example_classes) README.javademos > > +# Note the Java binding classes are actually generated in the java bindings > +# directory (path = "plplot.core"). Since the examples classes are # > +# generated here (path = "plplot.examples") but both must be included in the > +# jar file, this later is generated here. > + > +plplotjavadir = $(datadir)/java/ > +plplotjava_DATA = plplot.jar > + > +$(top_builddir)/bindings/java/jar-stamp: > + ( cd $(top_builddir)/bindings/java ; make jar-stamp ) > + > +plplot.jar: $(example_classes) $(top_builddir)/bindings/java/jar-stamp > + $(JAR) -cf plplot.jar -C $(top_builddir)/bindings/java/ plplot \ > + -C . plplot > + > endif > > install-data-hook: > if enable_java > ( cd $(DESTDIR)$(examples_javadir) ; mv -f Makefile.examples Makefile ) > - ( cd $(DESTDIR)$(datadir)/java ; jar -cf plplot.jar plplot ; \ > - rm -rf plplot) > endif > > -# Note the java package is actually assembled in the java bindings directory. > -# Fastjar doesn't update packages properly so we need to do it all in one go. > -plplot/examples/%.class : %.java > +.java.class: > $(JAVAC) $(AM_JAVACFLAGS) $(JAVACFLAGS) $< -d . -classpath $(PLPLOT_CLASSPATH) > + cp plplot/examples/$@ . > + > +CLEANFILES = $(example_classes) plplot.jar > > clean-local: > rm -rf plplot > Index: examples/java/Makefile.examples.in > =================================================================== > RCS file: /cvsroot/plplot/plplot/examples/java/Makefile.examples.in,v > retrieving revision 1.3 > diff -u -r1.3 Makefile.examples.in > --- examples/java/Makefile.examples.in 1 Jul 2004 09:35:17 -0000 1.3 > +++ examples/java/Makefile.examples.in 12 Jul 2004 08:34:50 -0000 > @@ -19,37 +19,38 @@ > # along with the file PLplot; if not, write to the Free Software > # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > > -JAVAC = javac > +JAVAC = @JAVAC@ > PLPLOT_CLASSPATH = @JAVADATA_HARDDIR@/plplot.jar > > example_classes = \ > - plplot/examples/x01.class \ > - plplot/examples/x02.class \ > - plplot/examples/x03.class \ > - plplot/examples/x04.class \ > - plplot/examples/x05.class \ > - plplot/examples/x06.class \ > - plplot/examples/x07.class \ > - plplot/examples/x08.class \ > - plplot/examples/x09.class \ > - plplot/examples/x10.class \ > - plplot/examples/x11.class \ > - plplot/examples/x12.class \ > - plplot/examples/x13.class \ > - plplot/examples/x14.class \ > - plplot/examples/x15.class \ > - plplot/examples/x16.class \ > - plplot/examples/x17.class \ > - plplot/examples/x18.class \ > - plplot/examples/x19.class \ > - plplot/examples/x22.class > + x01.class \ > + x02.class \ > + x03.class \ > + x04.class \ > + x05.class \ > + x06.class \ > + x07.class \ > + x08.class \ > + x09.class \ > + x10.class \ > + x11.class \ > + x12.class \ > + x13.class \ > + x14.class \ > + x15.class \ > + x16.class \ > + x17.class \ > + x18.class \ > + x19.class \ > + x22.class > > all: $(example_classes) > > clean: > - rm -rf plplot > + rm -rf plplot $(example_classes) > > -plplot/examples/%.class : %.java > +.java.class: > $(JAVAC) $(AM_JAVACFLAGS) $(JAVACFLAGS) $< -d . -classpath $(PLPLOT_CLASSPATH) > + cp plplot/examples/$@ . > > .SUFFIXES: .java .class |
From: Rafael L. <rla...@us...> - 2004-07-13 09:50:25
|
* Andrew Ross <and...@us...> [2004-07-13 09:14]: > The original message never got through to me - I guess it must be > sourceforge playing up. I've had a look at these changes and it seems > reasonable to me. Your experience with automake is much more than > mine. I originally tried something similar but didn't get it to work. > Your solution looks neater. > > Reading the documentation it seems that java support is starting > to make it's way into automake, but it's certainly not complete yet > and doesn't seem to quite fit our needs. Hopefully this will change in > the future. > > I'm happy for you to submit these changes anyway. I will commit them soon, such that it will be easier for anyone to test them. My changes do not make the Java support perfect yet, but they make it better than the previous one in many aspects. Please, test it and fix any bugs that I introduced. -- Rafael |
From: Andrew R. <and...@us...> - 2004-07-13 13:03:52
|
On Tue, Jul 13, 2004 at 11:48:34AM +0200, Rafael Laboissiere wrote: > * Andrew Ross <and...@us...> [2004-07-13 09:14]: > > > The original message never got through to me - I guess it must be > > sourceforge playing up. I've had a look at these changes and it seems > > reasonable to me. Your experience with automake is much more than > > mine. I originally tried something similar but didn't get it to work. > > Your solution looks neater. > > > > Reading the documentation it seems that java support is starting > > to make it's way into automake, but it's certainly not complete yet > > and doesn't seem to quite fit our needs. Hopefully this will change in > > the future. > > > > I'm happy for you to submit these changes anyway. > > I will commit them soon, such that it will be easier for anyone to test > them. My changes do not make the Java support perfect yet, but they make it > better than the previous one in many aspects. Please, test it and fix any > bugs that I introduced. Your changes work fine for me, however the .jar file now only contains the .class files again. Alan was keen that we include the java source and README.javademos as well so it was a complete package. Andrew |
From: Alan W. I. <ir...@be...> - 2004-07-13 16:51:52
|
On 2004-07-13 14:03+0100 Andrew Ross wrote: > On Tue, Jul 13, 2004 at 11:48:34AM +0200, Rafael Laboissiere wrote: >> I will commit them soon, such that it will be easier for anyone to test >> them. My changes do not make the Java support perfect yet, but they make it >> better than the previous one in many aspects. Please, test it and fix any >> bugs that I introduced. > > Your changes work fine for me, however the .jar file now only contains > the .class files again. Alan was keen that we include the java source and > README.javademos as well so it was a complete package. Rafael, I have just tried a fresh build, check, install, and ./plplot-test.sh for installed examples, and everything is working fine for my free-java-sdk java environment. However, there is the incomplete jar file problem already mentioned by Andrew, and also you should remove the installed $prefix/share/java/plplot tree since all those files will be in $prefix/share/java/plplot.jar (once that is complete). Also, there is no reason to include the legacy handcrafted interface, PLStream.java, in the tarball. Andrew, yes please on Geoffrey's idea to go back to using the PLStream class. However, PLStream.java should be left in cvs. I still refer to that legacy hand-crafted interface when trying to figure out the swig-generated interface, but of course there is no reason to leave the legacy interface in the tarball (see remark to Rafael above). My major cable ISP tells me they are still trying to get the mistaken blacklisting removed, and they hope this will be resolved in the next few days. (I speculate the cause of the trouble is some mis-communication between my ISP and blacklisters as to which of the millions of IP addresses owned by my cable ISP are "dynamic" and therefore discriminated against by the blacklisters and which are "static". The distinction between the two is quite blurry for any major cable ISP since many of their "dynamic" IP addresses for computers in fact remain unchanged for years.) I am getting all my mail from SF fine, but the effect of the mistaken blacklisting of my ISP's SMTP server is everything I send to SF bounces so far. That is why I am dealing with several related topics in this e-mail and sending this to individual e-mail addresses as well as SF. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <rla...@us...> - 2004-07-13 19:00:58
|
* Alan W. Irwin <ir...@be...> [2004-07-13 09:51]: > However, there is the incomplete jar file problem already mentioned by > Andrew, [...] Fixed in CVS. I have now: $ jar -tf examples/java/plplot.jar META-INF/MANIFEST.MF README.javaAPI plplot/ plplot/core/ plplot/core/PLplot.class plplot/core/plplotjavac.class plplot/core/plplotjavacConstants.class plplot/core/SWIGTYPE_p_p_char.class plplot/core/plplotjavacJNI.class plplot/core/PLStreamc.class plplot/core/config.class README.javademos x01.java x02.java x03.java x04.java x05.java x06.java x07.java x08.java x09.java x10.java x11.java x12.java x13.java x14.java x15.java x16.java x17.java x18.java x19.java x22.java plplot/ plplot/examples/ plplot/examples/x22.class plplot/examples/x19.class plplot/examples/x18.class plplot/examples/x17.class plplot/examples/x16.class plplot/examples/x15.class plplot/examples/x14.class plplot/examples/x13.class plplot/examples/x12.class plplot/examples/x11.class plplot/examples/x10.class plplot/examples/x09.class plplot/examples/x08.class plplot/examples/x07.class plplot/examples/x06.class plplot/examples/x05.class plplot/examples/x04.class plplot/examples/x03.class plplot/examples/x02.class plplot/examples/x01.class Is this correct? [ I must say that, despite all my efforts to make things neater, the Java configuration/build code is overly convoluted! ] > [...] and also you should remove the installed $prefix/share/java/plplot > tree since all those files will be in $prefix/share/java/plplot.jar (once > that is complete). This is also fixed in CVS. However, I noticed that the README.* and *.java files are installed in $(datadir)/java. Was it the case before my changes? At any rate, I will have to remove the files from this directory for the Debian packages, because it does not correspond to the usual practice (only *.jar files are installed in /usr/share/java). When building the Debian package, I will put those files in /usr/share/doc/libplplot9-java, which is a better place. > Also, there is no reason to include the legacy handcrafted interface, > PLStream.java, in the tarball. I am not responsible for this. I think that removing the related files from javafiles, javaclasses, and EXTRA_DIST in bindings/java/Makefile.am would be enough, wouldn't it? -- Rafael |
From: Alan W. I. <ir...@be...> - 2004-07-13 20:03:07
|
On 2004-07-13 21:00+0200 Rafael Laboissiere wrote: > * Alan W. Irwin <ir...@be...> [2004-07-13 09:51]: > >> However, there is the incomplete jar file problem already mentioned by >> Andrew, [...] > > Fixed in CVS. I have now: > > $ jar -tf examples/java/plplot.jar > META-INF/MANIFEST.MF > README.javaAPI > plplot/ > plplot/core/ > plplot/core/PLplot.class > plplot/core/plplotjavac.class > plplot/core/plplotjavacConstants.class > plplot/core/SWIGTYPE_p_p_char.class > plplot/core/plplotjavacJNI.class > plplot/core/PLStreamc.class > plplot/core/config.class > README.javademos > x01.java > x02.java > x03.java > x04.java > x05.java > x06.java > x07.java > x08.java > x09.java > x10.java > x11.java > x12.java > x13.java > x14.java > x15.java > x16.java > x17.java > x18.java > x19.java > x22.java > plplot/ > plplot/examples/ > plplot/examples/x22.class > plplot/examples/x19.class > plplot/examples/x18.class > plplot/examples/x17.class > plplot/examples/x16.class > plplot/examples/x15.class > plplot/examples/x14.class > plplot/examples/x13.class > plplot/examples/x12.class > plplot/examples/x11.class > plplot/examples/x10.class > plplot/examples/x09.class > plplot/examples/x08.class > plplot/examples/x07.class > plplot/examples/x06.class > plplot/examples/x05.class > plplot/examples/x04.class > plplot/examples/x03.class > plplot/examples/x02.class > plplot/examples/x01.class > > Is this correct? No, the README.javademos and x??.java files belong under plplot/examples. Also, README.javaAPI belongs under plplot/core. Finally, we need in plplot/core all the java files corresponding to the *.class files there. > > However, I noticed that the README.* and *.java files are installed in > $(datadir)/java. Was it the case before my changes? No, these files should not be installed as separate files at all. Instead, the should just be in the jar file under the appropriate directory there like they were before (see above comment). >> Also, there is no reason to include the legacy handcrafted interface, >> PLStream.java, in the tarball. > > I am not responsible for this. I think that removing the related files from > javafiles, javaclasses, and EXTRA_DIST in bindings/java/Makefile.am would be > enough, wouldn't it? I have removed the mention of the legacy PLStream.java from Makefile.am. (See my latest commit.) I believe this means it won't be installed or put into the tarball. This is a good thing, but OTOH I would like to keep this file in cvs for a while longer because it is still useful to java/swig interface developers for reference purposes). Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <rla...@us...> - 2004-07-13 21:58:53
|
* Alan W. Irwin <ir...@be...> [2004-07-13 13:00]: > No, the README.javademos and x??.java files belong under plplot/examples. > Also, README.javaAPI belongs under plplot/core. Finally, we need in > plplot/core all the java files corresponding to the *.class files there. Fixed in CVS. I have now here: $ dpkg -L libplplot9-java /. /usr /usr/lib /usr/lib/jni /usr/lib/jni/plplotjavac_wrap.so /usr/lib/jni/plplotjavac_wrap.la /usr/lib/jni/plplotjavac_wrap.a /usr/share /usr/share/java /usr/share/java/plplot.jar /usr/share/doc /usr/share/doc/libplplot9 /usr/share/doc/libplplot9/examples /usr/share/doc/libplplot9/examples/java /usr/share/doc/libplplot9/examples/java/README.javademos /usr/share/doc/libplplot9/examples/java/x01.java /usr/share/doc/libplplot9/examples/java/x02.java /usr/share/doc/libplplot9/examples/java/x03.java /usr/share/doc/libplplot9/examples/java/x04.java /usr/share/doc/libplplot9/examples/java/x05.java /usr/share/doc/libplplot9/examples/java/x06.java /usr/share/doc/libplplot9/examples/java/x07.java /usr/share/doc/libplplot9/examples/java/x08.java /usr/share/doc/libplplot9/examples/java/x09.java /usr/share/doc/libplplot9/examples/java/x10.java /usr/share/doc/libplplot9/examples/java/x11.java /usr/share/doc/libplplot9/examples/java/x12.java /usr/share/doc/libplplot9/examples/java/x13.java /usr/share/doc/libplplot9/examples/java/x14.java /usr/share/doc/libplplot9/examples/java/x15.java /usr/share/doc/libplplot9/examples/java/x16.java /usr/share/doc/libplplot9/examples/java/x17.java /usr/share/doc/libplplot9/examples/java/x18.java /usr/share/doc/libplplot9/examples/java/x19.java /usr/share/doc/libplplot9/examples/java/x22.java /usr/share/doc/libplplot9/examples/java/Makefile /usr/share/doc/libplplot9-java $ jar -tf /usr/share/java/plplot.jar META-INF/MANIFEST.MF plplot/ plplot/core/ plplot/core/README.javaAPI plplot/core/plplotjavacConstants.java plplot/core/plplotjavac.java plplot/core/SWIGTYPE_p_p_char.java plplot/core/plplotjavacJNI.java plplot/core/PLplot.java plplot/core/PLStreamc.java plplot/core/config.java plplot/core/PLplot.class plplot/core/plplotjavac.class plplot/core/plplotjavacConstants.class plplot/core/SWIGTYPE_p_p_char.class plplot/core/plplotjavacJNI.class plplot/core/PLStreamc.class plplot/core/config.class plplot/ plplot/examples/ plplot/examples/x22.java plplot/examples/x19.java plplot/examples/x18.java plplot/examples/x17.java plplot/examples/x16.java plplot/examples/x15.java plplot/examples/x14.java plplot/examples/x13.java plplot/examples/x12.java plplot/examples/x11.java plplot/examples/x10.java plplot/examples/x09.java plplot/examples/x08.java plplot/examples/x07.java plplot/examples/x06.java plplot/examples/x05.java plplot/examples/x04.java plplot/examples/x03.java plplot/examples/x02.java plplot/examples/x01.java plplot/examples/README.javademos plplot/examples/x22.class plplot/examples/x19.class plplot/examples/x18.class plplot/examples/x17.class plplot/examples/x16.class plplot/examples/x15.class plplot/examples/x14.class plplot/examples/x13.class plplot/examples/x12.class plplot/examples/x11.class plplot/examples/x10.class plplot/examples/x09.class plplot/examples/x08.class plplot/examples/x07.class plplot/examples/x06.class plplot/examples/x05.class plplot/examples/x04.class plplot/examples/x03.class plplot/examples/x02.class plplot/examples/x01.class -- Rafael |
From: Alan W. I. <ir...@be...> - 2004-07-13 23:42:57
|
On 2004-07-13 23:57+0200 Rafael Laboissiere wrote: > * Alan W. Irwin <ir...@be...> [2004-07-13 13:00]: > >> No, the README.javademos and x??.java files belong under plplot/examples. >> Also, README.javaAPI belongs under plplot/core. Finally, we need in >> plplot/core all the java files corresponding to the *.class files there. > > Fixed in CVS. I have now here: > > $ dpkg -L libplplot9-java > /. > /usr > /usr/lib > /usr/lib/jni > /usr/lib/jni/plplotjavac_wrap.so > /usr/lib/jni/plplotjavac_wrap.la > /usr/lib/jni/plplotjavac_wrap.a [snip] The snipped part looks good as far as I can quickly tell and assuming your debian install locations are identical to PLplot cvs install locations. However, I would remove the above plplotjavac_wrap.la and plplotjavac_wrap.a files (just like we do for the device driver dynamically loadable shared objects). > > $ jar -tf /usr/share/java/plplot.jar [snip] The snipped part looks good. Thanks for getting the results back to the way they were. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <rla...@us...> - 2004-07-14 10:46:43
|
* Alan W. Irwin <ir...@be...> [2004-07-13 16:35]: > On 2004-07-13 23:57+0200 Rafael Laboissiere wrote: > > >* Alan W. Irwin <ir...@be...> [2004-07-13 13:00]: > > > >>No, the README.javademos and x??.java files belong under plplot/examples. > >>Also, README.javaAPI belongs under plplot/core. Finally, we need in > >>plplot/core all the java files corresponding to the *.class files there. > > > >Fixed in CVS. I have now here: > > > > $ dpkg -L libplplot9-java > > /. > > /usr > > /usr/lib > > /usr/lib/jni > > /usr/lib/jni/plplotjavac_wrap.so > > /usr/lib/jni/plplotjavac_wrap.la > > /usr/lib/jni/plplotjavac_wrap.a > [snip] > > The snipped part looks good as far as I can quickly tell and assuming your > debian install locations are identical to PLplot cvs install locations. Yes, they are. > However, I would remove the above plplotjavac_wrap.la and > plplotjavac_wrap.a files Okay. > (just like we do for the device driver dynamically loadable shared > objects). My recollection is vague, but I think that we have to keep the /usr/lib/plplot5.3.1.cvs/driversd/*.la files, otherwise libltdl does not work. -- Rafael |
From: Alan W. I. <ir...@be...> - 2004-07-14 15:10:41
|
On 2004-07-14 12:45+0200 Rafael Laboissiere wrote: >> However, I would remove the above plplotjavac_wrap.la and >> plplotjavac_wrap.a files > > Okay. > >> (just like we do for the device driver dynamically loadable shared >> objects). > > My recollection is vague, but I think that we have to keep the > /usr/lib/plplot5.3.1.cvs/driversd/*.la files, otherwise libltdl does not > work. Oops! You are absolutely right. Bad analogy. A much better analogy is the dynamically loadable shared object we use for our python interface wrapper, _plplotcmodule.so. As in that case, *.la and *.a are not needed for the java interface wrapper so I am glad you are removing them. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <rla...@us...> - 2004-07-14 18:46:28
|
* Alan W. Irwin <ir...@be...> [2004-07-14 08:04]: > Oops! You are absolutely right. Bad analogy. A much better analogy is the > dynamically loadable shared object we use for our python interface wrapper, > _plplotcmodule.so. As in that case, *.la and *.a are not needed for the > java interface wrapper so I am glad you are removing them. Should I change bindings/java/Makefile.am to remove them in or only do it in the Debian package? -- Rafael |
From: Alan W. I. <ir...@be...> - 2004-07-14 23:19:45
|
On 2004-07-14 20:45+0200 Rafael Laboissiere wrote: > * Alan W. Irwin <ir...@be...> [2004-07-14 08:04]: > >> Oops! You are absolutely right. Bad analogy. A much better analogy is the >> dynamically loadable shared object we use for our python interface wrapper, >> _plplotcmodule.so. As in that case, *.la and *.a are not needed for the >> java interface wrapper so I am glad you are removing them. > > Should I change bindings/java/Makefile.am to remove them Yes. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the PLplot scientific plotting software package (plplot.org), the Yorick front-end to PLplot (yplot.sf.net), the Loads of Linux Links project (loll.sf.net), and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Rafael L. <rla...@us...> - 2004-07-15 08:45:12
|
* Alan W. Irwin <ir...@be...> [2004-07-14 16:09]: > On 2004-07-14 20:45+0200 Rafael Laboissiere wrote: > > >* Alan W. Irwin <ir...@be...> [2004-07-14 08:04]: > > > >>Oops! You are absolutely right. Bad analogy. A much better analogy is > >>the > >>dynamically loadable shared object we use for our python interface > >>wrapper, > >>_plplotcmodule.so. As in that case, *.la and *.a are not needed for the > >>java interface wrapper so I am glad you are removing them. > > > >Should I change bindings/java/Makefile.am to remove them > > Yes. Done in CVS. -- Rafael |