I have committed changes implementing the plan I sketched yesterday.
A basic install now installs just the include files needed for
client-side programming; to get all the include files, also say
I have verified that the header files installed by default are enough
to build the /interfaces and /bin directories, with two exceptions:
1. pg_dump.c includes a bunch of backend header files, mostly from the
src/include/catalog directory. This could perhaps be worked around,
but since pg_dump has always been pretty closely tied to the backend,
I'm not sure it's worth the trouble.
2. libpq's MULTIBYTE support pulls in a number of backend source files
which in turn want to include some backend-only headers. I'm going to
leave it to the MULTIBYTE gurus to clean that up if they feel like it.
We had talked about making separate 'client' and 'server' devel RPMs
to correspond to the minimal and full header sets. However, I measure
the extra install footprint at not very much over a megabyte, so maybe
it's not worth the trouble. If Lamar wants to just install the full
header set as part of the existing postgres-devel RPM, I won't object.
BTW, I have not done anything about Peter E's concern about config.h
polluting client namespaces. That's a valid concern but we'll have
to come back to it another day.
regards, tom lane
In response to
pgsql-hackers by date
|Next:||From: Bruce Momjian||Date: 2001-02-10 02:55:12|
|Subject: Link problems|
|Previous:||From: Bruce Momjian||Date: 2001-02-10 01:45:48|
|Subject: Re: [HACKERS] Open 7.1 items|
pgsql-interfaces by date
|Next:||From: Sasha||Date: 2001-02-10 13:09:44|
|Subject: Problem with JDBC driver: rs.next() is always null|
|Previous:||From: Hiroshi Inoue||Date: 2001-02-09 23:10:57|
|Subject: RE: 7.1 beta 3 Linux ODBC BEGIN Behaviour|