[OGR-ODBC]--with-odbc sets ODBC_SETTING to external instead of yes

[nsavard@…]

I compiled gdal on Redhat 9 with the ODBC support.  I did a "make install".  I
issued a "./ogrinfo --formats".  The ODBC support was not available.  

This same procedure worked well on Mac OCX.  What makes this procedure worked on
Mac OCX and not on Linux 9?  Email below described what I did to trouble shooted
this compilation problem and what is Frank solution to this problem.


------------------------
Email
-----------------------
Normand Savard wrote:
Frank,

I'm sending this question to this list because I'm assuming the ODBC support is
not accessible for all right now.  I compiled gdal with the ODBC support.  I did
a "make install".  I issued a "./ogrinfo --formats".  The ODBC support was not
available.

I compiled gdal/ogr on Redhat Linux 9.  The configuration settings is as follow:

./configure --prefix=/opt/mapserver/ --with-odbc=/usr/local
--with-png=/opt/mapserver/ --with-libz=/opt/mapserver --with-jpeg=/opt/mapserver

I pasted below a snippet of the output from this previous command.

I ran "make" and redirected the ouput to a file.  I edited this file and tried
to find the section where ODBC is compiled between the  `make[2]: Entering
directory  /home/src/gdal-cvs/ogr/ogrsf_frmts' line and the  make[2]: Leaving
directory `/home/src/gdal-cvs/ogr/ogrsf_frmts' line (see ...>>>>>>HERE from the
make output below) without success.

I then looked to the "configure" command output.  The  ODBC support is external.
 I checked the "GNUmakefile" rules in "gdal/ogr/ogrsf_formats" and the
"SUBDIRS-external" is not included in the "foreach" loop.  Could it be the problem?

I know that Zak succeeded to compile gdal with the ODBC support.  Can you give
me a hint on what is going on?
...
 ODBC support:              external
 OCI support:               no


Normand,

The problem turns out to be that using the --with-odbc option sets
ODBC_SETTING to external instead of yes which some others stuff
expects.  I have committed a modified configure that does this properly.
However, the quick fix is to edit GDALmake.opt and change
"ODBC_SETTING = external" to "ODBC_SETTING = yes".

Best regards,

-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent




------------------------------------------------------
Solution proposed by Frank to make it worked on Linux
------------------------------------------------------

[warmerdam]

I believe this is now fixed in CVS. 

[nsavard@…]

It is not committed unless I misundertood something because the problem was
reported January 16 th 2004 and the last logged change was done January 13 th 2004.

Anyway, I updated the source from the CVS and I executed the "configure" command
again.  I then checked the output from the "make" command.  I could not find the
following section:

.....
make[3]: Leaving directory `/home/src/gdal-cvs/ogr/ogrsf_frmts/vrt'
make -C odbc
make[3]: Entering directory `/home/src/gdal-cvs/ogr/ogrsf_frmts/odbc'
...

And the ODBC driver format is not available from the "ogrinfo --formats" command.

Also the following question is not answered:

What makes the initial "configure" worked on Mac OCX and not on Linux 9? 

[warmerdam]

Normand, 

Indeed, the configure change did not seem to have been committed properly for
some reason (my fault).  It should be committed now. 

I don't know why things worked for you on MacOS X.  As far as I can see there
is no way the build could have included ODBC support properly if you provided
a --with-odbc switch with an explicit path.  My guess would be that you didn't
use --with-odbc=<path>, you hand fixed the GDALmake.opt file, or you built it
before more recent changes which introduced the problem. 

Is it really worth investigating why it worked on MacOS X? 

[nsavard@…]

To answer this question:  "Is it really worth investigating why it worked on
MacOS X?".  No, it is just to know if MacOS X is behaving diffently in order to
build tests in consequence.  I'll check the fix.