Re: pgsql-server: > Please find enclose a submission - Mailing list pgsql-committers

Given your analysis it seems we have already chosen the best solution
--- shame we can't include that #ifdef stuff from a central file though.

---------------------------------------------------------------------------

Fabien COELHO wrote:
>
> Dear Tom,
>
> > I am not any keener than you on this particular approach ... the nesting
> > of ifdefs in the makefiles seems mighty ugly.
>
> I agree with you.
>
> > But I'd like to find a way to clean it up, not just claim that we don't
> > need to do it.
>
> At least six suggestions, make your choice:
>
> (1) submitted with the first version: having a separate makefile
>     for pgxs, and use "make -f the-pgxs-makefile target"
>     -> the pgxs makefile is very similar to the contrib one.
>     -> it looked a burden to have two sets of makefiles to be maintained.
>     -> thus Peter suggested that it was not a good idea, and I agreed.
>
> (2) having the ifdef stuff in the common part included by contrib
>     makefile, contrib/contrib-global.mk. done in submission 3 I think.
>     -> it was breaking the "vpath" feature, because of a chicken-and-egg
>        problem on the definition of top_srcdir, which required two separate
>        includes, although one include is fine with pgxs.
>     -> thus Peter rejected it.
>        I agree that existing things must not be broken.
>
> (3) the ifdef stuff is put in every makefile. done in submission 4.
>     -> this is the current status in dev.
>     -> it solves both previous issues.
>     -> Tom finds it ugly, and he is right;-)
>
> (4) remove in-source tree compilation, so that there is only pgxs.
>     -> that would make much simpler makefiles
>     -> that would break the vpath feature.
>     -> that would mean that compiling/installing contrib must
>        be done AFTER the server is compiled and installed.
>        From an administrator point of view, I don't see that as a big issue.
>        That's the case with apache external modules and I have never found
>        it a problem in the past years.
>     -> However ISTM that it is a political decision that pg-managers
>        are not akin to make.
>
> (5) improve pgxs so that it works easilly both in-source and out-source.
>     But I don't know how to that cleanly and without the kind of
>     ifdef that are already there and are found ugly... Maybe solution
>     (2) could be improved so that it works fine for vpath? As I'm not
>     a vpath user, I'm not sure whether it can be achieved. Peter would
>     be the best man to look into that, but the previous version he
>     proposed broke pgxs because it required to include Makefile.global
>     which is not there under pgxs.
>
> (6) provide the same functionnality with any other mean:
>     a special executable like apache "apxs" command, or whatever.
>
>     I did not chose this approach because it looked quite simple
>     to adapt the existing contrib infrastructure to make it work
>     outside of the source tree... indeed, all the work was already
>     done and it was more a re-packaging issue.
>
> If someone else want to do it, fine with me, I don't stick to my
> particular implementation: I just want the feature;-)
>
> Have a nice day,
>
> --
> Fabien Coelho - coelho@cri.ensmp.fr
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073