Fabien COELHO wrote:
> Please find attached a patch which provides a working infrastructure
> for pg extensions such as new gist-based indexes, functions, types...


- 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 

- 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?


Reply via email to