testing dist tarballs

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Christoph Berg <myon(at)debian(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: testing dist tarballs
Date: 2023-05-24 21:24:37
Message-ID: 20230524212437.jm6e3iiehtehivbh@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Hi,

On 2023-05-23 14:51:03 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > I guess I need to go and check how long the "release" tarball generation
> > takes...
>
> It's quick except for the documentation-generating steps. Maybe
> we could test that part only once?

First thing I noticed that 'make dist' doesn't work in a vpath, failing in a
somewhat obscure way (likely because in a vpath build the the copy from the
source dir doesn't include GNUMakefile). Do we expect it to work?

Besides docs, the slowest part appears to be gzip --best and then bzip2, as
those runs serially and takes 11 and 13 seconds respectively here...

The first thing I tried was:
make -j8 dist GZIP=pigz BZIP2=pbzip2

unfortunately that results in

pigz: abort: cannot provide files in GZIP environment variable

echo GZIP=pigz >> src/Makefile.custom
echo BZIP2=pbzip2 >> src/Makefile.custom

reduces that to

real 1m6.472s
user 1m28.316s
sys 0m5.340s

real 0m54.811s
user 1m42.078s
sys 0m6.183s

still not great...

OTOH, we currently already build the docs as part of the CompilerWarnings
test. I don't think there's a reason to test that twice?

For me make distcheck currently fails:

In file included from ../../src/include/postgres.h:46,
from hashfn.c:24:
../../src/include/utils/elog.h:79:10: fatal error: utils/errcodes.h: No such file or directory
79 | #include "utils/errcodes.h"
| ^~~~~~~~~~~~~~~~~~
compilation terminated.
make[3]: *** [<builtin>: hashfn.o] Error 1

at first I thought it was due to my use of -j8 - but it doesn't even work
without that.

That's due to MAKELEVEL:

submake-generated-headers:
ifndef NO_GENERATED_HEADERS
ifeq ($(MAKELEVEL),0)
$(MAKE) -C $(top_builddir)/src/backend generated-headers
endif
endif

So the distcheck target needs to reset MAKELEVEL=0 - unless somebody has a
better idea?

Separately, it's somewhat confusing that we include errcodes.h etc in
src/backend/utils, rather than its final location, in src/include/utils. It
works, even without perl, because copying the file doesn't require perl, it's
just generating it...

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2023-05-24 21:35:52 Re: testing dist tarballs
Previous Message Bruce Momjian 2023-05-24 16:19:06 pgsql: doc: PG 16 relnotes, wording adjustments

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2023-05-24 21:28:03 Re: PostgreSQL 16 Beta 1 release announcement draft
Previous Message Justin Pryzby 2023-05-24 21:05:22 Re: [PATCH] psql: \dn+ to show size of each schema (and \dA+ for AMs)