Re: Remove distprep - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Remove distprep
Date
Msg-id 20230929160030.2czaxjcjxv7toakt@alap3.anarazel.de
Whole thread Raw
In response to Re: Remove distprep  (Peter Eisentraut <peter@eisentraut.org>)
List pgsql-hackers
Hi,

On 2023-08-23 12:46:45 +0200, Peter Eisentraut wrote:
> Subject: [PATCH v4] Remove distprep
> 
> A PostgreSQL release tarball contains a number of prebuilt files, in
> particular files produced by bison, flex, perl, and well as html and
> man documentation.  We have done this consistent with established
> practice at the time to not require these tools for building from a
> tarball.  Some of these tools were hard to get, or get the right
> version of, from time to time, and shipping the prebuilt output was a
> convenience to users.
> 
> Now this has at least two problems:
> 
> One, we have to make the build system(s) work in two modes: Building
> from a git checkout and building from a tarball.  This is pretty
> complicated, but it works so far for autoconf/make.  It does not
> currently work for meson; you can currently only build with meson from
> a git checkout.  Making meson builds work from a tarball seems very
> difficult or impossible.  One particular problem is that since meson
> requires a separate build directory, we cannot make the build update
> files like gram.h in the source tree.  So if you were to build from a
> tarball and update gram.y, you will have a gram.h in the source tree
> and one in the build tree, but the way things work is that the
> compiler will always use the one in the source tree.  So you cannot,
> for example, make any gram.y changes when building from a tarball.
> This seems impossible to fix in a non-horrible way.

I think it might be possible to fix in a non-horrible way, just that the
effort doing so could be much better spent on other things.

It's maybe also worth mentioning that this does *not* work reliably with vpath
make builds either...


> The make maintainer-clean target, whose job it is to remove the
> prebuilt files in addition to what make distclean does, is now just an
> alias to make distprep.  (In practice, it is probably obsolete given
> that git clean is available.)

FWIW, I find a "full clean" target useful to be sure that we don't produce
"untracked" build products. Do a full build, then run "full clean", then see
what remains.


>  88 files changed, 169 insertions(+), 409 deletions(-)

It might be worthwhile to split this into a bit smaller chunks, e.g. depending
on perl, bison, flex, and then separately the various makefile bits that are
all over the tree.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Eager page freeze criteria clarification
Next
From: Tom Lane
Date:
Subject: Re: Annoying build warnings from latest Apple toolchain