From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Should we use make -k on the buildfarm? |
Date: | 2010-11-08 20:01:35 |
Message-ID: | 4CD8571F.7010705@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 11/08/2010 02:49 PM, Peter Eisentraut wrote:
> On lör, 2010-11-06 at 14:45 -0400, Andrew Dunstan wrote:
>> Here's the list of tests from a recent run, leaving out stopping and
>> starting the installed postmaster, and locale specifiers:
>>
>> SCM-checkout
>> configure
>> make
>> check
>> make-contrib
>> make-install
>> install-contrib
>> initdb
>> install-check
>> pl-install-check
>> contrib-install-check
>> ecpg-check
>>
>> Currently, the implied dependency list is in this order. We could have
>> "make-contrib" depend only on "make" rather than "check",
>> "pl-install-check" and "contrib-install-check" depend on "initdb",
>> and "ecpg-check" depend on "make" rather than anything that comes
>> after. I think that's about the limit of what we could sensibly relax
> In principle you could get this down to
>
> SCM-checkout
> configure
> make -k world
> make -k check-world # target doesn't exist yet
> make -k install-world
> initdb
> make -k installcheck-world
>
> That way you don't have to update the buildfarm code every time a new
> test suite is added.
>
No, we can't do that for several reasons. Here are a couple.
First, the buildfarm doesn't build the docs. That's a deliberate
decision, based on the fact that not every member has the required
software installed. And second these targets only exist for 9.0 and/or
later.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitriy Igrishin | 2010-11-08 20:02:26 | Re: proposal: plpgsql - iteration over fields of rec or row variable |
Previous Message | Pavel Stehule | 2010-11-08 20:00:34 | Re: proposal: plpgsql - iteration over fields of rec or row variable |