Обсуждение: the contrib tree clean up
I start clean up in the contrib tree. Now I have fixed some Makefiles.
My idea is add to all contrib modules Makefile (and allow install
contrib matter) and to top-contrib-directory Makefile.global that define
some definition relevant for contrib only. This Makefile include standard
../src/Makefile.global too. IMHO is not good idea add some setting
relevant (only) for contrib-tree to standard (src) Makefile.global. IMHO all in contrib need a little standardize.
A question, how install these files from contrib? (I inspire with debian
PG packages)
*.sql - $(POSTGRESDIR)/sql*.so - $(POSTGRESDIR)/modulesexec-binary - $(POSTGRESDIR)/bin*.doc
- $(POSTGRESDIR)/docIn the current contrib is come dead code. What remove this code from
contrib tree to ftp.postgresql.org to some dead-code directory. It will
still accessible on ftp if anyone want it, and the contrib will correct.
Comments? Karel
The current state in contrib:
apache_logging - Use it anyone? IMHO good candidate for *delete* or remove to some web page like
"Tipshow use PostgreSQL"....
bit - impossible compile, last change '2000/04/12 17:14:21' It is already in main tree. Delete?
earthdistance - I fix it, it is probably ready now.
likeplanning - haven't Makefile, I fix it
linux - haven't Makefile, I fix it
mSQL - Use it anyone?, I haven't idea where install it. It is a "file.c". Delete?
noupdate - I fix (add Makefile) it, it is probably ready now, but needs this anyone?
unixdate - haven't Makefile
Probably ready:arraydatetimefindoidjoinsfulltextindexisbn_issnlomiscutilodbcpg_dumplopgbenchspi string
soundex toolsuser_locksvacuumlo
os2client - I fix Makefile, but it's still breaked:
gcc -I. -I../../src/include -DFRONTEND -DTCPIPV4 -DHAVE_CRYPT_H -c
../../src/backend/libpq/pqcomm.c
In file included from ../../src/include/storage/ipc.h:28, from ../../src/include/storage/bufmgr.h:18,
from ../../src/include/storage/bufpage.h:18, from ../../src/include/access/htup.h:17,
from ../../src/include/tcop/dest.h:55, from ../../src/include/libpq/libpq.h:23,
from../../src/backend/libpq/pqcomm.c:77:
config.h:16: warning: DEF_PGPORT' redefined
../../src/include/config.h:202: warning: this is the location of the
previous definition
config.h:18: warning: HAVE_TERMIOS_H' redefined
../../src/include/config.h:270: warning: this is the location of the
previous definition
config.h:19: warning: HAVE_ENDIAN_H' redefined
../../src/include/config.h:231: warning: this is the location of the
previous definition
----------> Commets?
On Tue, 13 Jun 2000, Karel Zak wrote: > > I start clean up in the contrib tree. Now I have fixed some Makefiles. > My idea is add to all contrib modules Makefile (and allow install > contrib matter) and to top-contrib-directory Makefile.global that define > some definition relevant for contrib only. This Makefile include standard > ../src/Makefile.global too. IMHO is not good idea add some setting > relevant (only) for contrib-tree to standard (src) Makefile.global. > > IMHO all in contrib need a little standardize. > > A question, how install these files from contrib? (I inspire with debian > PG packages) > > *.sql - $(POSTGRESDIR)/sql > *.so - $(POSTGRESDIR)/modules ipmeter, when it installs their ports.so file, puts it in $(POSTGRESDIR)/lib/modules ... sounds like an appropriate place to me ...
On Wed, 14 Jun 2000, Peter Eisentraut wrote: > On Tue, 13 Jun 2000, Karel Zak wrote: > > > Now I have fixed some Makefiles. My idea is add to all contrib modules > > Makefile (and allow install contrib matter) and to > > top-contrib-directory Makefile.global that define some definition > > relevant for contrib only. > > Try to keep everything as local as possible, don't include > ../src/Makefile.global either if at all possible. Make it a > contrib/Makefile.global.in so you can substitute Autoconf variables into > it. But I want primary ../src/Makefile.global for compilation, because here is all defined. I not sure if is good define it (same) again in contrib. If we will (for example) defined path to LIBPG in two Makefiles we must maintain these Makefiles. IMHO it is bad --- same data is good share not define it twice. A solution is put Makefile.global to top directory (over src) and use it in all trees (contrib/docs/src). What? > > A question, how install these files from contrib? (I inspire with > > debian PG packages) > > > > *.sql - $(POSTGRESDIR)/sql > > @datadir@ (/usr/local/pgsql/share) > > > *.so - $(POSTGRESDIR)/modules > > @libdir@ (or perhaps libexecdir, depending on what it does) > > > exec-binary - $(POSTGRESDIR)/bin > > @bindir@ Agree. > > > *.doc - $(POSTGRESDIR)/doc > > Is there any documentation in contrib? It is a little mazy, but yes. > See <http://www.gnu.org/prep/standards.html#SEC40> for the GNU makefile > standards. Using anything else will just conflict with the Makefile > cleanup I'm currently doing and thus be inconsistent again at the end. :) > > > The current state in contrib: > > > > apache_logging - Use it anyone? IMHO good candidate for *delete* or remove > > to some web page like "Tips how use PostgreSQL".... > > The latter sounds good but why not keep it? I can create in contrib dir "tips" and somethig like 'apache_logging' can be put here. > > > bit - impossible compile, last change '2000/04/12 17:14:21' > > It is already in main tree. Delete? > > I think this will be included into the main tree. I detele it. Who not agree? > > > earthdistance - I fix it, it is probably ready now. > > > > likeplanning - haven't Makefile, I fix it > > This will be merged into the main tree. I know, but in 7.1 (Tom)? > > linux - haven't Makefile, I fix it > > This definitely doesn't need a make file. All need Makefile :-) 'make install' > > mSQL - Use it anyone?, I haven't idea where install it. It is a > > "file.c". Delete? > > I think this is a wrapper library, hence @libdir@. OK. > > datetime > > I think this is obsoleted by your to_char() and friends. I look at it, and if you right, I delete it. Karel
Karel Zak <zakkr@zf.jcu.cz> writes:
>>>> likeplanning - haven't Makefile, I fix it
>>
>> This will be merged into the main tree.
> I know, but in 7.1 (Tom)?
I think we could delete contrib/likeplanning --- there shouldn't be
any need for it in 7.1.
regards, tom lane