Re: Call for port reports - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Call for port reports
Date
Msg-id 3805.24.211.141.25.1102403329.squirrel@www.dunslane.net
Whole thread Raw
In response to Re: Call for port reports  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane said:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> Peter Eisentraut wrote:
>>> ./configure --prefix=SOMEWHERE --enable-thread-safety --with-tcl \
>>> --with-perl --with-python --with-krb5 --with-pam -with-openssl
>>> make
>>> make install
>>> make check
>
>> buildfarm actually runs in this order:
>
>> make
>> make check
>> make contrib
>> make install
>> ... more steps
>
>> I assume that's ok.
>
> There is a difference, which is that on some (most?) platforms the
> latter sequence will involve "make check" invoking the libpq shared
> library that was installed by the previous iteration of "make install".
>
> I'm not sure that this matters a whole lot for the buildfarm, since at
> worst it would result in failures for one test cycle when libpq.so
> changes incompatibly.  But it's important to realize what you are
> testing.
>

The script installs to a non-standard location ( <buildroot>/<branch>/inst )
and removes the installation at the end of each run. In fact, it refuses to
run if this directory exists when the run starts, precisely so we don't get
clobbered by previous runs.

Also, note that since it stops on the first step that fails, the failure
would persist rather than lasting one cycle, had we not prevented it in the
first place.

cheers

andrew




pgsql-hackers by date:

Previous
From: Thomas Hallgren
Date:
Subject: Re: how can i add my own procedural language?
Next
From: Sibtay Abbas
Date:
Subject: spi and other languages