Fabien COELHO wrote:
> Please find attached a patch which provides a working infrastructure
> for pg extensions such as new gist-based indexes, functions, types...
Comments:
- Regarding GNUmakefile.in changes: files in directory foo/ must be
handled by a makefile in directory foo/, so these changes must be moved
to a makefile in config/.
- Please don't invent new targets like light-install, install-local.
Just install everything in the install target.
- The uninstall target may only remove what it installed, not "*".
- Don't invent new installation directories; there are enough already.
Platform dependent data files (which these are) go into/under
$(pkglibdir).
- Referring to the renaming of all makefiles under contrib/: I'm not in
favor of naming makefiles Makefile.foo; it should be foo.mk. This
makes it easier for tools that recognize files by extension.
- I think this is a good approach
PGXS := $(shell pg_config --pgxs)
include $(PGXS)/pgxs.mk
but why not
PGXS := $(shell pg_config --pgxs)
include $(PGXS)
- Incidentally, the above will fail if pg_config is not installed (yet),
so it can't be used in the contrib/ directories. (The contrib
directories are at least cleaned by the top-level makefile, this this
is a must-fix failure.)
- In Makefile.global: -L$(pkglibdir) is not necessary. There are not
libraries to link at build time in there.
- -I$(includedir) and -L$(libdir) cannot be used. In an average
installation that resolves to -I/usr/include and -L/usr/lib, which
breaks GCC and other compilers.
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
