Hiroshi Inoue writes:
> Provide subdirectories for compilation e.g. ./iODBC
> ./unixODBC ./Windows. Each subdirectory would have
> its own makefile at least and specific sources like
> gpps.c for iDOBC if necessary. Common sources are
> still in the current directory but the objects would
> be put into the each subdirectories when the compilation
> is invoked.
Something like that, but where do you install the drivers? E.g., you'd
have ./iODBC/libpsqlodbc.so and ./unixODBC/libpsqlodbc.so, but when you
install them the names clash again. We should probably encode the meaning
of the file in the file name, such as libpsqliodbc.so and
libpsqlunixodbc.so. (A separate Windows version is probably not
necessary, since you rarely use the same source tree to build both on Unix
and on Windows.)
This could be easy to arrange with two make targets that link in a
different library, but the subject of include files is tricky. I'm not
sure if it's reasonable to have both iODBC and unixODBC installed since
they both install some of the same files, such as sql.h and sqlext.h.
> I'm not sure about how to change the current iODBC
> support. I didn't find the library in iODBC like
> odbcinst in unixODBC.
The version 3.0.5 I'm looking at contains a library libiodbcinst which
contains the function SQLGetPrivateProfileString.
> If there are some people who expect continuous iODBC support, gpps.c
> should be removed or improved at least.
Probably removed.
But another thing that occurred to me is that if you want to use ODBC on
Unix for ApplixWare or StarOffice you don't necessarily have a driver
manager installed with header files and such, so we probably need to keep
the standalone version.
--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
