On Jan 7, 2010, at 4:36 PM, Hans Dieter Pearcey wrote:

Perl's toolchain went through a lot of growing pains in order to let
distributions control their own installation process (./Build) rather than
invoking an external binary (make).

You may want to sidestep some of this pain from the beginning by having the
install process always run something from . instead of depending on make. e.g.


Maybe your client can even assume make && make install && make installcheck if
any of those executables aren't present, but being able to override them easily
is a huge win for future extensibility.

Even if make is currently the standard, well, that was true of EUMM too; have
you ever tried to extend it?

I've never written a postgres extension, obviously, so all of the above may not
be relevant.
Yes, if there wasn't already significant investment in `make` for PostgreSQL, I'd be looking into something else. AS it is, though, that's what the project already supports (via a whole slew of useful targets included in PGXS), and so that's what the PGAN client will use. If PostgreSQL core ever comes up with some other standard for installing extensions, PGAN client will be updated to support it. But writing the installer itself is not what PGAN is about at all.

And yes, I have extended a Makefile, for [pgTAP](http://github.com/theory/pgtap/blob/master/Makefile). It was painful for someone who knows nothing about `make`, but it works well enough.



Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 3 of 11 | next ›
Discussion Overview
groupcpan-workers @
postedJan 7, '10 at 10:36p
activeJan 8, '10 at 6:04p



site design / logo © 2021 Grokbase