[Gdal-dev] Added new macro AX_LIB_ORACLE_OCI

[Mateusz Loskot]

Hi,

I added new macro autoconf detecting Oracle OCI libraries,
available in CVS.
The macro is called AX_LIB_ORACLE_OCI and is defined
in m4/ax_oracle_oci.m4 file.
Generally, nothing revolutionary has been added,
but only a few new features.

Motivation
------------------------

The motivation was to support Oracle in versions >= 10, also the free
Oracle 10g Express Edition.
As I've discovered, the version 10.x has inroduced new
library libnnz10 - a security library - that's required and
used by OCI client library (libclntsh).
So, when building GDAL with OCI support from Oracle 10,
both linker flags -lclntsh and -lnnz10 are required.
When building GDAL with earlier versions (< 10) of Oracle client
libraries, only -lclntsh flag is used.

And the AX_LIB_ORACLE_OCI macro does care about all this differences
detection and appropriate flags setting.

The macro can be used to extend following variables in autotools
output files:

AC_SUBST(ORACLE_OCI_CFLAGS)
AC_SUBST(ORACLE_OCI_LDFLAGS)
AC_SUBST(ORACLE_OCI_VERSION)

It also sets HAVE_ORACLE_OCI="yes" or HAVE_ORACLE_OCI="no".


Features
------------------------

Now, ./configure script supports following OCI options:

1. --with-oci=[ARG]

Where ARG is a placeholder for:
- [DIR] - explicitly given path to ORACLE_HOME location
- yes   - then the macro checks for ORACLE_HOME environment variable
          and tests if it points to a directory location
- no    - macro disables Oracle OCI support

2.  --with-oci-include=[DIR] and --with-oci-lib=[DIR]

These two options enable user to pass paths to libs and
headers separately. If Oracle will change structure of folders
under ORACLE_HOME, it will be still possible to point new locations.

As DIR placeholder suggests, it's *only* possible to pass path using
these options. yes|no values are not supported.



Usage examples + output
------------------------

1. Explicitly request to disable Oracle OCI support

$ ./configure --with-oci=no

or

$ ./configure --without-oci

In both cases, the ./configure will print follownig messages:

...
checking if Oracle support is enabled... no

...
  OCI support:               no


2. Explicitly request to enable Oracle OCI

a) using predefined ORACLE_HOME environment variable

$ echo $ORACLE_HOME
/usr/lib/oracle/xe/app/oracle/product/10.2.0/server
$ ./configure --with-oci=yes

b) passing ORACLE_HOME

$ ./configure --with-oci=/path/to/oracle/home

c) passing lib/include paths separately

$ ./configure \
	--with-oci-include=/path/to/oracle/include \
	--with-oci-lib=/path/to/oracle/somewhere/lib


In all a), b), c) cases above, the ./configure script output is similar:

...
checking for Oracle OCI headers in
/usr/lib/oracle/xe/app/oracle/product/10.2.0/server/rdbms/public... yes
checking for Oracle OCI libraries in
/usr/lib/oracle/xe/app/oracle/product/10.2.0/server/lib... yes
checking if Oracle OCI version is >= 8.1.7... yes
checking for Oracle version >= 10.x to use -lnnz10 flag... yes
checking if Oracle support is enabled... yes

...
  OCI support:               yes


As you can see in the message above, the line:
"checking for Oracle version >= 10.x to use -lnnz10 flag... yes"
shouts about adding (or not) libnnz10 to linker flags.




If anyone could test it with older versions of Oracle (< 10),
please give me some feedback.

If you have any questions, comments or bug reports,
please drop me a note.

There are other similar macros waiting to incorporate to GDAL,
like macros detecting PostgreSQL, MySQL and SQLite.
I hope to add them in future.


Cheers
-- 
Mateusz Loskot
http://mateusz.loskot.net