From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Aidan Van Dyk <aidan(at)highrise(dot)ca> |
Cc: | Ivan Sergio Borgonovo <mail(at)webthatworks(dot)it>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: development setup and libdir |
Date: | 2010-01-31 04:26:48 |
Message-ID: | 4B650688.8080100@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Aidan Van Dyk wrote:
> * Andrew Dunstan <andrew(at)dunslane(dot)net> [100130 19:55]:
>
>
>> If I am developing, say, a new
>> perl facility, I expect to develop and test using a private installation
>> of perl, and not screw up my system's perl. It's the same with postgres.
>>
>
> But, perl was a bad example. If you're just trying to develop a new
> "perl module", something that other perl scripts can use, to require you
> to provide a completely private copy of complete perl, instead of the
> perfectly identical (other than paths) version the system provides is a
> bit much...
>
> I'm not arguing that the PGXS gripes Ivan has are valid, but your perl
> example probably *supports* his case more than you think...
>
>
My example was not of a perl module, but of some extra facility inside
the perl engine. But I take your point. OTOH, perl is not a running
server, unlike Postgres.
In any case, the points others have made about needing to develop
against a build with cassert, debug and depends turned on are valid.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Euler Taveira de Oliveira | 2010-01-31 04:44:13 | Re: development setup and libdir |
Previous Message | Aidan Van Dyk | 2010-01-31 04:15:39 | Re: development setup and libdir |