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. > > ./build > ./install > ./installcheck > > 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. Best, David
