Update of /cvsroot/plplot/plplot/bindings/java
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv23737/bindings/java
Modified Files:
Tag: CFDIR
Makefile.am README.javaAPI plplotjavac.i
Log Message:
Merged with HEAD. Documentation for the CFDIR branch is extensively added
to cf/README. The CFDIR branch is now ready for testing.
Index: Makefile.am
===================================================================
RCS file: /cvsroot/plplot/plplot/bindings/java/Makefile.am,v
retrieving revision 1.25
retrieving revision 1.25.2.1
diff -u -d -r1.25 -r1.25.2.1
--- Makefile.am 10 Feb 2004 17:36:13 -0000 1.25
+++ Makefile.am 22 Feb 2004 20:57:02 -0000 1.25.2.1
@@ -64,12 +64,13 @@
nodist_plplotjavac_wrap_la_SOURCES = plplotjavac_wrap.c
-# Do not use -no-undefined here since symbols should be resolved by
-# java when it dynamically loads this shared object.
+# no-undefined should work on all platforms here since libplplot should
+# resolve all symbols.
plplotjavac_wrap_la_LDFLAGS = \
-rpath $(ourexecjavadir) \
-module \
-avoid-version \
+ -no-undefined \
$(libplplot)
if enable_java
Index: README.javaAPI
===================================================================
RCS file: /cvsroot/plplot/plplot/bindings/java/README.javaAPI,v
retrieving revision 1.7
retrieving revision 1.7.4.1
diff -u -d -r1.7 -r1.7.4.1
--- README.javaAPI 9 Oct 2003 21:08:08 -0000 1.7
+++ README.javaAPI 22 Feb 2004 20:57:02 -0000 1.7.4.1
@@ -1,6 +1,6 @@
Here is how to generate the new Java interface to PLplot using swig.
-PREREQUISITE: swig-1.3.17 (or later) must be installed if you are trying the
+PREREQUISITE: swig-1.3.21 (or later) must be installed if you are trying the
java interface to PLplot from the cvs version of PLplot. If you are doing
this from a PLplot tarball, it should have all the swig-created files in it
already, and you shouldn't need swig at all.
@@ -39,72 +39,62 @@
For the curious, here are some more details about the 'make' and 'make
install' steps above.
-'make' automatically runs swig (version 1.3.17 or above) on plplotjavac.i
-(which does an include of plplotcapi.i) to generate all the interface files
-that are needed for further processing. To understand these two files and
-what they do, you should read the latest java interface documentation from
-swig version 1.3.17. The result should be a complete interface (aside
-from the limitations mentioned below) for Java to the PLplot common API.
+'make' automatically runs swig (version 1.3.21 or above) on plplotjavac.i
+(which does an include of ../swig-support/plplotcapi.i) to generate all the
+interface files that are needed for further processing. To understand these
+two *.i files and what they do, you should read the latest java interface
+documentation from swig version 1.3.21. The result should be a complete
+interface (aside from the limitations mentioned below) for Java to the
+PLplot common API.
The files generated by swig are necessary java files and plplotjavac_wrap.c.
(These files should already be pre-generated if you have received PLplot as
-a tarball). 'make' builds the wrapper library libplplotjava$(LIB_TAG).so
-from plplotjavac_wrap.c. 'make' also builds the class files corresponding to
-the swig-generated java files, the configured config.java file, and the
-hand-crafted PLStreamc.java file. (Note the c suffix on the name. In
-contrast, PLStream.java and javabind.c are historical files we are only
-keeping around for reference, see below.) The relevant java files and
-corresponding class files that are compiled from them make up the
-plplot.core package.
+a tarball). 'make' builds the java interface shared object module (DLL)
+plplotjavac_wrap.SOBJEXT from plplotjavac_wrap.c. 'make' also builds the
+class files corresponding to the swig-generated java files, the configured
+config.java file, and the hand-crafted PLStreamc.java file. (Note the c
+suffix on the name. In contrast, PLStream.java and javabind.c are
+historical files we are only keeping around for reference, see below.) The
+relevant java files and corresponding class files that are compiled from
+them make up the plplot.core package.
'make install' installs the relevant java and class files that are part of
-the plplot.core package in /usr/local/plplot/lib/java/plplot/core, installs
-the module (DLL) for the java PLplot interface in the same location, and also
-installs (from ../../examples/java) the example java scripts and
-corresponding class files that are part of the plplot.examples package into
-/usr/local/plplot/lib/java/plplot/examples. For more details about the
-examples, please see ../../examples/java/README.javademos or the installed
-version of that file in /usr/local/plplot/lib/java/plplot/examples.
+the plplot.core package in $prefix/lib/java/plplot/core, installs the
+shared object module (DLL) plplotjavac_wrap.SOBJEXT for the java PLplot
+interface in the same location, and also installs (from ../../examples/java)
+the example java scripts and corresponding class files that are part of the
+plplot.examples package into $prefix/lib/java/plplot/examples. For
+more details about the examples, please see
+../../examples/java/README.javademos or the installed version of that file
+in /usr/local/plplot/lib/java/plplot/examples.
Here is how to add a new function to the Java API for PLplot:
-Edit plplotcapi.i. Find a function with the same argument types that you
-have in your new function, and copy those argument types and argument names
+Edit ../swig-support/plplotcapi.i. (If you want just a Java interface to
+this PLplot function and not a python or any other interface, then wrap your
+entry with #ifdef SWIG_JAVA ... #endif, but ordinarily you will be adding
+functions for all swig-generated interfaces so you will not use a java-only
+#ifdef at all.) Find a function with the same argument types that you have
+in your new function, and copy those argument types and argument names
*EXACTLY*. The typedefs in plplotjavac.i process argument type and argument
-name patterns to produce the required java files and java interface code.
-So give it the same pattern (white space doesn't matter), and you will get
-the same argument processing that worked before for the old function.
-In the unlikely event that you have a new pattern of argument list, then it
-is time to dig into the Java interface documentation for swig.
+name patterns to produce the required java files and java interface code. So
+give it the same pattern (white space doesn't matter), and you will get the
+same argument processing that worked before for the old function. In the
+unlikely event that you have a new pattern of argument list, then it is time
+to dig into the Java interface documentation for swig.
Limitations of the current swig-generated Java interface to PLplot:
-(1) The new Java interface to PLplot should be complete (aside from the 3
-functions mentioned below), but that functionality has not been thoroughly
-tested. All the example scripts run fine which is an excellent sign, but
-those only exercise a subset of the Java PLplot API. In particular, none of
-the many 'plg' style functions that obtain floating point or integer
-information from the PLplot environment have been exercised. You will
-have to look up the JNI tutorial from Sun to see how to access variables
-returned as arguments in the Java environment.
-
-(2) plgdev, plgfnam, and plgver are the 3 PLplot functions that return
-character strings in their argument. These 3 functions are not currently
-implemented (i.e., they are commented out in plplotcapi.i and the relevant
-typemaps which take care of how to process the arguments of these routines
-are commented out in plplotjavac.i). From the perspective of my limited JNI
-knowledge the generated code in plplotjavac_wrap.c looked fine, but it just
-didn't work (acted like no-op) when I tried using plgver in x01.java. (That
-call has now been commented-out.) I suspect trying to return a java string
-through a JNI argument list is just not supported. All the examples in the
-JNI tutorial passed the string back as the function return value. So
-probably the way to implement these 3 functions is to use helper functions
-which return a string like all the JNI examples, then generate the
-swig-based interface to the helper functions in a natural way. But I will
-leave those experiments to somebody else who is motivated by a huge urge to
-have plgdev, plgfnam, or plgver implemented in Java.
+* The new Java interface to PLplot should be complete, but that
+functionality has not been thoroughly tested. All the example scripts run
+fine which is an excellent sign, but those only exercise a subset of the
+Java PLplot API. In particular, very few of the many 'plg' style functions
+that obtain floating point or integer information from the PLplot
+environment have been exercised. You will have to look up the JNI tutorial
+from Sun or the swig documentation to see how to access variables returned
+as arguments in the Java environment.
-(3) A user-friendly (UF) wrapper to the raw java interface should be made to
+* A user-friendly (UF) wrapper to the raw java interface should be made to
give us a variety of different simplified argument lists similarly to the
way plplot.py wraps the plplotc extension module. I assume that java is
more powerful than C so that it makes sense to write the UF interface in
@@ -115,12 +105,12 @@
about ORing in pls.PL_PARSE_NOPROGRAM to the parse mode parameter. This
idiosyncrasy of Java should be hidden for the UF interface.
-If someone will show me the way by writing such a java wrapper with just one
-argument list simplification, I can fill out the rest following the
+If someone will show me (AWI) the way by writing such a java wrapper with
+just one argument list simplification, I can fill out the rest following the
user-friendly simplified argument list variations that have been implemented
in plplot.py.
-(4) Each example has a rather ugly combination of two commands:
+* Each example has a rather ugly combination of two commands:
PLStreamc plsdummy = new PLStreamc();
plplotjavac pls = new plplotjavac();
@@ -137,7 +127,7 @@
I said above, I can fill out all the required argument list variations once
somebody shows me how to make just one of them.
-(5) Only the default java double-precision can be used from Java. That is
+* Only the default java double-precision can be used from Java. That is
what the examples use (by default) and that is what works. I believe the way
to do this properly with swig is simply to make both single and double
precision versions of the PLplot API description, and the two possible
@@ -149,7 +139,7 @@
and all double-precision java entities are transformed to the appropriate C
precision (either single or double) without problems.
-(6) The callback functions should be done properly so that Java methods can
+* The callback functions should be done properly so that Java methods can
be used for transformations for the full 3-D PLplot API. This approach
would be similar to the way the Python interface fully implements the
callback functions (see the mypltr definition and use in xw09.py). For now,
@@ -157,7 +147,7 @@
what is done for the Tcl interface rather than the preferred complete
callback approach used for the Python interface.
-Alan W. Irwin (last updated on 2003 October 1.)
+Alan W. Irwin (last updated on 2004-02-15.)
_________________________________________________________________
The following notes (written by Geoffrey Furnish with some minor editing
Index: plplotjavac.i
===================================================================
RCS file: /cvsroot/plplot/plplot/bindings/java/plplotjavac.i,v
retrieving revision 1.9
retrieving revision 1.9.4.1
diff -u -d -r1.9 -r1.9.4.1
--- plplotjavac.i 17 Jan 2004 16:41:37 -0000 1.9
+++ plplotjavac.i 22 Feb 2004 20:57:02 -0000 1.9.4.1
@@ -775,42 +775,35 @@
/***************************
String returning functions
+ Adopt method in SWIG-1.3.21/Examples/java/typemap/example.i
****************************/
-%typemap(jni) char *OUTPUT "jstring"
-%typemap(jtype) char *OUTPUT "String"
-%typemap(jstype) char *OUTPUT "String"
-%typemap(javain) char *OUTPUT "$javainput"
-%typemap(javaout) char *OUTPUT {
- return $jnicall;
-}
-
-/* The code below updates the jstring argument rather than returning a
- * jstring because the fundamental function we are wrapping here has type
- * void, and that is wrapped by swig as a void JNI function, etc. Anyhow, I
- * think the generated code is fine and should work for say, plgver, but it
- * doesn't. (See commented out code in x01.java).
- * Probably, the best thing to do is to make a helper function for
- * each of plgdev, plgfnam, and plgver which returns a character string, and
- * then allow swig to wrap these helper functions, but I will leave that to
- * someone else. Thus, for now, comment out all of this as well as
- * the plgdev, plgfnam, and plgver prototypes. */
+/* Define the types to use in the generated JNI C code and Java code */
+%typemap(jni) char *OUTPUT "jobject"
+%typemap(jtype) char *OUTPUT "StringBuffer"
+%typemap(jstype) char *OUTPUT "StringBuffer"
-// temporary
-#if 0
-/* This currently just used for plgdev, plgfnam, and plgver which apparently
- * have a limit of 80 bytes. But to (hopefully) be safe for any future use
- * have a 1000 byte limit here. */
-%typemap(in) char* OUTPUT (char buff[1000]){
- $1 = buff;
-}
+/* How to convert the C type to the Java(JNI) type */
%typemap(argout) char *OUTPUT {
- $input = (*jenv)->NewStringUTF(jenv, buff$argnum);
+
+ if($1 != NULL) {
+ /* Append the result to the empty StringBuffer */
+ jstring newString = (*jenv)->NewStringUTF(jenv, $1);
+ jclass sbufClass = (*jenv)->GetObjectClass(jenv, $input);
+ jmethodID appendStringID = (*jenv)->GetMethodID(jenv, sbufClass, "append", "(Ljava/lang/String;)Ljava/lang/StringBuffer;");
+ (*jenv)->CallObjectMethod(jenv, $input, appendStringID, newString);
+
+ /* Clean up the string object, no longer needed */
+ free($1);
+ $1 = NULL;
+ }
}
-%typemap(freearg) char *OUTPUT {}
+/* Prevent the default freearg typemap from being used */
+%typemap(freearg) char *OUTPUT ""
+
+/* Convert the jstype to jtype typemap type */
+%typemap(javain) char *OUTPUT "$javainput"
-// temporary
-#endif
/* Character arrays: */
%typemap(jni) (PLINT *p_argc, char **argv) "jobjectArray"

Update of /cvsroot/plplot/plplot/cf
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv23737/cf
Modified Files:
Tag: CFDIR
README drivers-pre.ac
Log Message:
Merged with HEAD. Documentation for the CFDIR branch is extensively added
to cf/README. The CFDIR branch is now ready for testing.
Index: README
===================================================================
RCS file: /cvsroot/plplot/plplot/cf/Attic/README,v
retrieving revision 1.10.2.2
retrieving revision 1.10.2.3
diff -u -d -r1.10.2.2 -r1.10.2.3
--- README 21 Feb 2004 13:03:20 -0000 1.10.2.2
+++ README 22 Feb 2004 20:57:04 -0000 1.10.2.3
@@ -6,7 +6,7 @@
------------
PLplot is a complex piece of software. It includes a core library, which
-may use external libraries like FreeType and Qhull), as well as several
+may use external libraries like FreeType and Qhull, as well as several
language bindings and drivers for a large number of devices and file
formats. This complexity reflects on its configuration system, which can be
considered a separate project in itself.
@@ -15,17 +15,17 @@
History
-------
-Version prior to 5.0.0 of PLplot already used Autoconf for its configuration
-system. At that time a home-brew technique for generating the Makefile from
-small fragments were used. The main drawbacks of this technique were the
-lack of portability in the generated Makefiles and the cross-platform
-problems for generating shared libraries, let alone the later dynamically
-loadable drivers.
+Versions of PLplot prior to 5.0.0 already used Autoconf for its
+configuration. At that time a home-brew technique for generating the
+Makefile from small fragments were used. The main drawbacks of this
+technique were the lack of portability in the generated Makefiles and the
+cross-platform problems for generating shared libraries, let alone
+dynamically loadable drivers.
At the end of 2001, a new effort started to port the configuration scheme to
-Automake and Libtool. This appeared in release 5.2.1, in April 2003. This
+Automake and Libtool. It appeared in release 5.2.1, in April 2003. This
was a huge overhaul of the PLplot configuration and we had to abandon the
-"flat" built paradigm where all the source files were copied to a temporary
+"flat" build paradigm where all the source files were copied to a temporary
directory and compiled there. Automake needed to have the source code
organized hierarchically with separate Makefile.am's for each directory.
@@ -33,40 +33,47 @@
code were kept in the configure.in file (renamed to configure.ac later).
Some of this legacy code related to old necessities, like diverting the
initial portion of configure.in to set default values correctly. Also, a
-sysloc.in file at the top-level directory was included by configure.in, but
-there was no logic behind
+sysloc.in file in top-level directory was used, but there was no logic
+behind the division of code between it and configure.in.
-In sum, the situation until the release of version 5.3.0 has been quite
-unsatisfactory, even if the configuration scheme have been continuously
+In sum, the situation until the release of version 5.3.0 was quite
+unsatisfactory, even if the configuration scheme has been continuously
improved since version 5.2.1. The code in configure.ac and sysloc.in was
-way too convoluted, not very robust as regards to changes in it, and
-daunting for the beginners. We then decided to reorganize the configuration
-code to addresses those issues.
+way too convoluted, besided being not very robust and daunting for the
+beginners. We then decided to reorganize the configuration code to addresses
+those issues.
The new configuration scheme
----------------------------
-Modernization, starts with AC_INIT (no diversion, default in PL_ARG_*)
+The main changes of the new configuration scheme involved the following:
-Port to Automake 1.8.2 and Libtool 1.5.2
+ * Port to Automake 1.8.2 and Libtool 1.5.2
-Modularization, cf dir, m4_include, aclocal scans cf for m4 files, no
-AT generated files at the topdir
+ * Modernization of many Autotools constructs
-Although the amount of changes in this commit is huge, configuration and
-build runs smoothly from a freshly checked out CVS tree, by doing:
+ * Resurrection of the cf/, which is used both for the Autotools
+ generated files and the new modular *.ac files.
+
+The most visible change is that the top directory is now quite clean. After
+a fresh cvs checkout, only the configure.ac file is now present. All the
+other configuration files are in the cf directory and are called *.ac. The
+bootstrap.sh script, which also used to be in the top directory is now in
+cf. In the tarball, all the files that used to be in the top dir
+(config.guess, config.sub, depcomp, missing, mkinstalldirs, ltmain.sh, etc)
+are now in cf.
- cf/bootstrap.sh
- ./configure
- make check
+Also in cf are files *.m4 which contain only calls to the AC_DEFUN macro.
+There are both imported files from third party projects (like gtk.m4 and
+swig.m4) and our own files (like acinclude.m4 and docbook.m4). They are
+scanned by aclocal and the needed macros are included in aclocal.m4.
-The code in configure.ac and cf/sysloc.in is still quite messy (BTW, this
-later file will soon disappear), because I have to move code around to get
-everything working. This state of affairs showed me how fragile and
-unmaintainable the previous scheme was. The files configure.ac,
-cf/sysloc.in and cf/docbook.m4 will be soon broken down in smaller pieces
-(cf/*.ac).
+The configure.ac script is quite clean and small now. It contains
+essentially calls to m4_include(cf/*.ac). Its clear structure can help new
+maintainers to understand the PLplot configuration scheme better. One of
+the big improvements now is that there is not diverted material at the
+beginning of the file. It starts in the canonical way, with AC_INIT.
The diverted stuff at the beginning of configure.ac have served many
purposes in the past:
@@ -81,11 +88,11 @@
(4) Set the $system variable and fix it for braindead Cray.
-I am sure that my changes regarding (1) will generate a lot of debate.
-People get used to have all the default values for the enable_* and with_*
-variables to be concentrated at the beginning of the configure.ac. That
-could be handy for the experienced developer, but is pretty
-non-maintainable and confusing for the new developers.
+My changes regarding (1) may be a matter of debate. People get used to have
+all the default values for the enable_* and with_* variables to be
+concentrated at the beginning of the configure.ac. That could be handy for
+the experienced developer, but is pretty non-maintainable and confusing for
+the new developers.
I think it is better to have the definition of default values close to
where the definition is actually defined. For that, two new macros were
@@ -102,34 +109,17 @@
The very nice side effect of these changes is that ./configure --help shows
now (at last!) the default values for all options. The problem before was
that we tried to use the shell variables in the help string, but they were
-not being interpolated. Only for this reason, my changes are already
-worth.
-
-As regards (2), Maurice cleaned up the diversion section of configure.ac
-recently, by noticing that there is now an official way to do it, namely
-through the environment variable CONFIG_SITE. However, this solution is
-broken in HEAD, since the values set in the CONFIG_SITE file override the
-values set by the options --with-* and --enable-* (it should be the
-contrary). In CFDIR, the situation is the same. Hence, in her private
-configuration startup file $CONFIG_SITE, the user has to do something like
-this:
-
- if test -z "$enable_octave" ; then enable_octave=yes ; fi
-
-It can also set a shell function for that:
+not being interpolated. Only for this reason, my changes are already worth.
- my_default() { eval "if test -z \"\$$1\"; then $1=$2 ; fi" ; }
- my_default enable_octave no
- my_default enable_f77 yes
- # etc.
-[This is plain Bourne shell, no bashisms here.]
+Drivers configuration
+---------------------
The previous system for setting driver/device options and variables was
quite convoluted. It contained three redundant lists: PL_DRIVER_LIST,
PL_DYNAMIC_DRIVER_LIST, and PL_device_driver_pair_list. This has been
-overly simplified now. There is a single comma-separated list now
-(PL_DEVICE_DRIVER_LIST) whose components are like:
+overly simplified now. In cf/drives-pre.ac, there is a single
+comma-separated list (PL_DEVICE_DRIVER_LIST) whose components are like:
device:driver:default
@@ -140,33 +130,63 @@
[...]
PL_ADD_DRIVERS(PL_DRIVERS_DEVICE_LIST)
-Between the two should come parts of the code that used to be in sysloc.in.
+Between the two calls above, driver specific configurations are included.
-The setting of the $system variable in (4) is completely obsoleted by the
-AC_CANONICAL_HOST variable. Besides that, it was just used to set the
-with_opt variable for the Cray system. BTW, this variable is not used
-anywhere else in PLplot. I got rid of it, together with other legacy stuff
-like with_profile and with_warn.
-Besides the diversion cleanup, several other minor changes have been done.
-One of them was to get rid of the has_tcl and has_tk variables, which were
-redundant to enable_tcl and enable_tk. Also, a cf/README is added to the
-project. It contains just a boilerplate now, but will be filled
-progressively.
+Bootstrapping PLplot
+--------------------
+Developers can bootstrap the PLplot package by launching the following
+command from the top-level directory:
+ cf/bootstrap.sh
-Bootstraping the package
-------------------------
+Automake >= 1.8.2 is mandated and Autoconf >= 2.59 and Libtool >= 1.5.2 or
+later of Libtool are recommended. The bootstrap.sh script will check the
+Automake version and will abort if the requirement above is not met.
-cf/bootstrap.sh
+The aclocal command will scan the cf directory for m4 macro definitions and
+will create an appropriate aclocal.m4. Notice that aclocal-1.7 had a
+different behavior and required the acinclude.m4 file to be present at the
+top level, which is not the case anymore.
-aclocal -> creation of aclocal.m4
+After running bootstrap.sh, the configuration goes further with the usual:
-./configure and so forth should be transparent
+ ./configure
+and everything should work as before.
+Overriding default values
+-------------------------
+Loading of user configuration files is possible through the environment
+variable CONFIG_SITE, which contains the name of the init file.
+Default options can be overridden like this:
+
+ if test -z "$enable_octave" ; then enable_octave=yes ; fi
+
+A shell function can also be used for that:
+
+ my_default() { eval "if test -z \"\$$1\"; then $1=$2 ; fi" ; }
+ my_default enable_octave no
+ my_default enable_f77 yes
+ # etc.
+
+[This is plain Bourne shell, no bashisms here.]
+
+
+Using a configuration cache file
+--------------------------------
+
+Since configure does a lot of tests, it takes quite a long time to complete.
+Developers may find interesting to use a cache file. This can be done like
+this:
+
+ ./configure --cache-file=config.cache
+
+(Notice that the above is equivalent to "./configure -C".)
+
+
+ -- Rafael Laboissiere <rafael@...> Sat Feb 21 18:42:18 CET 2004
- -- Rafael Laboissiere <rafael@...> Mon Feb 15 19:22:07 CET 2004
Index: drivers-pre.ac
===================================================================
RCS file: /cvsroot/plplot/plplot/cf/Attic/drivers-pre.ac,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -u -d -r1.1.2.1 -r1.1.2.2
--- drivers-pre.ac 22 Feb 2004 18:45:53 -0000 1.1.2.1
+++ drivers-pre.ac 22 Feb 2004 20:57:04 -0000 1.1.2.2
@@ -22,22 +22,18 @@
dnl along with the file PLplot; if not, write to the Free Software
dnl Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
-dnl Including a driver in the below list includes it by default.
-dnl Note that each driver should be treated separately even if
-dnl they are in the same source code file.
-dnl For example, the ps and psc drivers are defined in the ps.c source
-dnl code file.
-
-dnl N.B. This is ordered the same as the *driver pair* list below to help
-dnl humans keep the associations straight, but this is not necessary.
+dnl The configure option --enable-drivers will enable all drivers at once
+dnl You can enable/disable drivers either with configure options
+dnl (--enable-<driver> or --disable-<driver>) or via the cf_plplot.in file
+dnl (remember to use underscores instead of dashes here). You can disable
+dnl all drivers by default by using --disable-drivers.
-dnl Note specifically which drivers are known to be loadable. Eventually,
-dnl hopefully, every driver will show up on this list. However, we add them one
-dnl at a time since each will have its own peculiarities in the build process
-dnl (none missing at present).
+PL_ARG_ENABLE(drivers, [enable all device drivers], yes)
-dnl N.B. This is ordered the same as the *driver pair* list below to help
-dnl humans keep the associations straight, but this is not necessary.
+if test "$enable_dyndrivers" = "yes"; then
+ AC_DEFINE(ENABLE_DYNDRIVERS, [],
+ [Define if there is support for dynamically loaded drivers])
+fi
dnl We think of a "device" as the output medium. Could be a machine
dnl style (Tektronix, X11), or a file format (Postscript).
@@ -52,30 +48,15 @@
dnl once. To support this, we build an association list between devices
dnl and drivers. This will be inspected to build up the set of drivers
dnl to be compiled based on which devices are selected.
-
+dnl
+dnl The PL_DRIVERS_DEVICE_LIST defined below is a comma separated list of
+dnl <device>:<drive>:<enable_default> items. <enable_default> should be
+dnl "yes" or "no" and this will reflect in inlcusion/exclusion by default
+dnl (as shown by ./configure --help).
+dnl
dnl Ordered alphabetically by second in each pair (the driver) for human
dnl consumption, but this is not necessary.
-PL_ARG_ENABLE(drivers, [enable all device drivers], yes)
-
-# Set driver enable values
-#
-# You can enable/disable drivers either by the command line
-# (--enable-<driver> or --disable-<driver>) or via the cf_plplot.in file
-# (remember to use underscores instead of dashes here). You can disable
-# all drivers by default by using --disable-drivers.
-
-# Special cases
-
-# ----------------------------------------------------------------------------
-# Set flag to enable searching for dynloadable drivers, if appropriate.
-# ----------------------------------------------------------------------------
-
-if test "$enable_dyndrivers" = "yes"; then
- AC_DEFINE(ENABLE_DYNDRIVERS, [],
- [Define if there is support for dynamically loaded drivers])
-fi
-
builtin([define], [PL_DRIVERS_DEVICE_LIST], [
cgm:cgm:yes,
dg300:dg300:no,