Re: Plan for straightening out the include-file mess

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org, pgsql-interfaces(at)postgreSQL(dot)org
Subject: Re: Plan for straightening out the include-file mess
Date: 2001-02-10 02:47:32
Message-ID: 24345.981773252@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-interfaces

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
make install-all-headers

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

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2001-02-10 02:55:12 Link problems
Previous Message Bruce Momjian 2001-02-10 01:45:48 Re: [HACKERS] Open 7.1 items

Browse pgsql-interfaces by date

  From Date Subject
Next Message Sasha 2001-02-10 13:09:44 Problem with JDBC driver: rs.next() is always null
Previous Message Hiroshi Inoue 2001-02-09 23:10:57 RE: 7.1 beta 3 Linux ODBC BEGIN Behaviour