Re: pgsql-server: > Please find enclose a submission

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