FAQ

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

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

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

People

Translate

site design / logo © 2021 Grokbase