Re: Call for port reports

From: "Andrew Dunstan" <andrew(at)dunslane(dot)net>
To: <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <peter_e(at)gmx(dot)net>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Call for port reports
Date: 2004-12-07 07:08:49
Message-ID: 3805.24.211.141.25.1102403329.squirrel@www.dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane said:
> Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Fuhr 2004-12-07 08:34:23 Re: spi and other languages
Previous Message Sibtay Abbas 2004-12-07 07:05:28 spi and other languages