Tom Lane wrote:
>>Yeah. I think I'd be more concerned by core regression failures than
>>contrib build failures - especially as they are often likely to have
>>more far reaching consequences.
>>
>>
>
>Agreed. I guess that the order of importance of the pieces you have is
>
> build main (this includes building PLs)
> run main tests
> run PL tests
> build contrib
> run contrib tests
>
>
That's almost what we do, but it's a bit more complex. Slightly
simplified, the sequence runs something like this (PL checks only run on
HEAD or branches >8.0):
configure
make
make check
cd contrib && make
make install
cd $installdir && bin/initdb --no-locale data
cd $installdir && bin/pg_ctl -D data -w start
make installcheck
cd src/pl && make installcheck
cd contrib && make installcheck
cd $installdir && bin/pg_ctl -D data stop
>I'm not sure where the proposed-to-be-added multibyte regression tests
>go in this order. On practical grounds I would put them last; I rather
>suspect that porting failures in that code will be rare. Could be wrong
>though.
>
>
Yes, that makes sense. I don't know when I'll get time to make that
happen though.
>It's slightly annoying that the PLs are built as part of the main build;
>I would rather run the main tests and then try to build and test the PLs
>(that is, the ones that have external dependencies --- plpgsql can be
>treated as part of the core for our purposes here). Not sure if it's
>worth hacking the makefiles to make that possible.
>
>
>
>
I don't think so.
cheers
andrew
