On 2015-03-11 11:19:24 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
> > On 2015-03-10 22:06:37 -0300, Alvaro Herrera wrote:
> > > I don't think we care one bit whether these modules use pgxs, at least
> > > not currently. If we find any issues later on, it should be an easy fix
> > > anyway.
> >
> > I personally find it quite ugly to use pgxs for stuff in
> > src/bin. pgxs.mk says:
> > # This file contains generic rules to build many kinds of simple
> > # extension modules. You only need to set a few variables and include
> > # this file, the rest will be done here.
>
> I think if you s/extension// in the above paragraph, it makes complete
> sense to use it for the new src/bin modules.
No. The dependencies here are becoming completely ridiculous:
include $(top_builddir)/src/Makefile.global
include $(top_srcdir)/contrib/contrib-global.mk
-> NO_PGXS = 1 include $(top_srcdir)/src/makefiles/pgxs.mk -> ifndef PGXS ifndef NO_PGXS
$(errorpgxs error: makefile variable PGXS or NO_PGXS must be set) endif endif ... ifdef PGXS
# We assume that we are in src/makefiles/, so top is ... top_builddir := $(dir $(PGXS))../.. include
$(top_builddir)/src/Makefile.global ....
This is just an absurd maze. Not something we should spread even
further. It's bad enough that contrib uses it. But the purportedly
higher quality code (that's why we're moving it, right?) shoulnd't do
these hacks.
> > I don't object at all to introducing more generic rules for src/bin, but
> > that seems like a separate task. And one that should be done right not
> > just use some convenient hack. And you can't tell me that
> > +NO_PGXS = 1
> > +include $(top_srcdir)/src/makefiles/pgxs.mk
> > isn't a hack...
>
> Why not? It's the standard procedure for building modules outside the
> contrib/ source tree.
NO_PGXS = 1 is? Huh? You probably mean USE_PGXS? That's something
different.
> I'm okay with reformulating the makefiles after the move, so that these
> modules are built in our standard, simpler makefile conventions. Let's
> do that in a followup commit -- then each change is simpler. It's hard
> enough with all the ugly MSVC stuff.
-1.
Greetings,
Andres Freund
--Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services