Обсуждение: ODBC configure
Who's maintaining the ODBC configure and build stuff? There's a grave issue with ODBC linking in all kinds of makefiles, templates, header files, etc. from the main Postgres configure process. That creates problems for both sides: The main tree couldn't care less what ODBC needs tested and defined since it claims to have it's own configure script. I don't have a problem with ODBC having it's own configure script, if that's what's desired, but then it needs to be used unconditionally. Running the standalone and the integrated show at the same time doesn't work. I'd be more than happy to help fixing these issues but I just want to ask first who knows anything about it. One particular question is where the authorative source is: is it the PostgreSQL CVS or is it this psqlodbc-x.y.z.tar.gz file, whereever that came from? (Incidentally, I think the ODBC thing is simple enough to just use Automake on it and be done with it. Then we don't need any templates or port makefiles or whatever.) -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
> I don't have a problem with ODBC having it's own configure script, if > that's what's desired, but then it needs to be used unconditionally. > Running the standalone and the integrated show at the same time doesn't > work. > > I'd be more than happy to help fixing these issues but I just want to ask > first who knows anything about it. One particular question is where the Nikolaidis, Byron in Baltimore, Maryland, USA(byron.nikolaidis@home.com) rewrote and maintainsthe ODBC interface for Windows. > authorative source is: is it the PostgreSQL CVS or is it this > psqlodbc-x.y.z.tar.gz file, whereever that came from? Our CVS tree. > > (Incidentally, I think the ODBC thing is simple enough to just use > Automake on it and be done with it. Then we don't need any templates or > port makefiles or whatever.) -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
I wrote: > I don't have a problem with ODBC having it's own configure script, if > that's what's desired, but then it needs to be used unconditionally. > Running the standalone and the integrated show at the same time doesn't > work. Further investigation shows that the standalone build is completely broken and apparently no longer maintained. Thus, is there any point in trying to keep it? > (Incidentally, I think the ODBC thing is simple enough to just use > Automake on it and be done with it. Then we don't need any templates or > port makefiles or whatever.) FWIW, I just did tried that conversion and it's really very nice (after fixing some of shared-lib-on-linux-only funny business). So in case you wanna keep the separate build after all... -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
Peter Eisentraut <peter_e@gmx.net> writes:
> I wrote:
>> I don't have a problem with ODBC having it's own configure script, if
>> that's what's desired, but then it needs to be used unconditionally.
>> Running the standalone and the integrated show at the same time doesn't
>> work.
> Further investigation shows that the standalone build is completely broken
> and apparently no longer maintained. Thus, is there any point in trying to
> keep it?
AFAICS the only situation where a separate build of ODBC is really
useful is to build a Windows executable of the ODBC driver --- but
of course the autoconf stuff doesn't support that anyway.
For Unix purposes I'd be in favor of making ODBC just another interface
that's built as part of the main build ... but let's see what Lockhart
has to say about it. I think he was responsible for setting it up this
way in the first place, so maybe he's got a good reason for it.
regards, tom lane
> Who's maintaining the ODBC configure and build stuff?
Me, a little bit. I haven't changed anything in quite a while.
> There's a grave issue with ODBC linking in all kinds of makefiles,
> templates, header files, etc. from the main Postgres configure
> process.
Only for a "standalone" build afaik. An "integrated build" uses all
features from the main tree.
> That creates problems for both sides: The main tree couldn't care less
> what ODBC needs tested and defined since it claims to have it's own
> configure script.
> I don't have a problem with ODBC having it's own configure script, if
> that's what's desired, but then it needs to be used unconditionally.
> Running the standalone and the integrated show at the same time
> doesn't work.
Well, standalone and integrated are two separate features. We shouldn't
strip one at the expense of the other, but it may be that the standalone
version is completely unused? If so, we worked at this feature for no
good purpose, and it should be ignored until someone finds a real need
for it imho.
- Thomas
> The standalone build is broken at least for 7.0. I see that at some
> point you tried to get the top-level configure to invoke odbc's
> configure recursively to have a "distribution in the distribution".
> That is definitely the right way to do it if you want to keep the
> dichotomy. Somehow it seems that it didn't work for you, but at least
> it does work for me. Maybe we should re-enable that?
Your call. But afaik the "distro in the distro" technique does not allow
for a separate package, without requiring a lot of duplication in the
configure script at both levels.
> Btw., do you recall what the separate packaging was intended for?
The separate packaging was intended to address the point that, for some
apps, the *only* package needed to access a remote Postgres database was
the ODBC driver itself. So we wanted a way to build and install it
without requiring any other parts of Postgres to be installed.
At the time, I didn't have a *strong* feeling that this was essential,
but others suggested that it was.
Frankly, istm that the same kind of person who would want to build a
standalone ODBC driver might also be running a system for which RPMs or
some other packaging system is available, so perhaps we should back away
from the standalone capability on Unix systems. The small grey area in
users' knowledge and capabilities between "can build and install from
the source distro" to "needs a pre-built package" may be more trouble
than it is worth.
- Thomas
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
>> Btw., do you recall what the separate packaging was intended for?
> The separate packaging was intended to address the point that, for some
> apps, the *only* package needed to access a remote Postgres database was
> the ODBC driver itself. So we wanted a way to build and install it
> without requiring any other parts of Postgres to be installed.
I don't have a strong feeling that this is particularly essential for
ODBC alone. It's been suggested more than once that it might be nice
to be able to build clients without building the server --- but that
would cover libpq, psql, etc, not just the ODBC interface. (Bruce,
shouldn't there be a TODO item for that?)
It seems clear that the standalone ODBC config is suffering bit-rot,
and that that will be its normal state of existence given that no one
takes care to make it track changes to the top-level configure files.
So I'm in favor of ripping it out.
I would like to see us offer a client-only build procedure someday,
but I don't feel much urgency about it.
regards, tom lane
On Tue, 13 Jun 2000, Thomas Lockhart wrote: > Well, standalone and integrated are two separate features. We shouldn't > strip one at the expense of the other, but it may be that the standalone > version is completely unused? If so, we worked at this feature for no > good purpose, and it should be ignored until someone finds a real need > for it imho. The standalone build is broken at least for 7.0. I see that at some point you tried to get the top-level configure to invoke odbc's configure recursively to have a "distribution in the distribution". That is definitely the right way to do it if you want to keep the dichotomy. Somehow it seems that it didn't work for you, but at least it does work for me. Maybe we should re-enable that? Btw., do you recall what the separate packaging was intended for? -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden