Re: Tarball builds in the new world order

Peter Eisentraut writes: > On 29.04.24 18:14, Tom Lane wrote: >> OK. After poking at that for awhile, it seemed like "default to >> HEAD" fits into meson a lot better than "throw an error if the >> variable isn't set", so I switched to doing it like that. > This patch looks good to me. Pushed,

Re: Tarball builds in the new world order

On 29.04.24 18:14, Tom Lane wrote: Peter Eisentraut writes: On 26.04.24 21:24, Tom Lane wrote: Concretely, I'm proposing the attached. Peter didn't like PG_COMMIT_HASH, so I have PG_COMMIT_REFSPEC below, but I'm not wedded to that if a better name is proposed. This seems ok to me, but

Re: Tarball builds in the new world order

Peter Eisentraut writes: > On 26.04.24 21:24, Tom Lane wrote: >> Concretely, I'm proposing the attached. Peter didn't like >> PG_COMMIT_HASH, so I have PG_COMMIT_REFSPEC below, but I'm not >> wedded to that if a better name is proposed. > This seems ok to me, but note that we do have an

Re: Tarball builds in the new world order

On 26.04.24 21:24, Tom Lane wrote: Concretely, I'm proposing the attached. Peter didn't like PG_COMMIT_HASH, so I have PG_COMMIT_REFSPEC below, but I'm not wedded to that if a better name is proposed. Um, "refspec" leads me here ,

Re: Tarball builds in the new world order

On 26.04.24 21:24, Tom Lane wrote: Concretely, I'm proposing the attached. Peter didn't like PG_COMMIT_HASH, so I have PG_COMMIT_REFSPEC below, but I'm not wedded to that if a better name is proposed. This seems ok to me, but note that we do have an equivalent implementation in meson. If we

Re: Tarball builds in the new world order

Alvaro Herrera writes: > Why is it that the .gitrevision file is only created here, instead of > being added to the tarball that "git archive" produces? Adding an > argument like > --add-virtual-file $(distdir)/.gitrevision:$(GIT_REFSPEC) > to the git archive call should suffice. I think

Re: Tarball builds in the new world order

On 2024-Apr-26, Tom Lane wrote: > --- mk-one-release.orig 2024-04-23 17:30:08.983226671 -0400 > +++ mk-one-release2024-04-26 15:17:29.713669677 -0400 > @@ -39,13 +39,17 @@ mkdir pgsql > git archive ${gitref} | tar xf - -C pgsql > > # Include the git ref in the output tarballs > +#

Re: Tarball builds in the new world order

Concretely, I'm proposing the attached. Peter didn't like PG_COMMIT_HASH, so I have PG_COMMIT_REFSPEC below, but I'm not wedded to that if a better name is proposed. regards, tom lane diff --git a/GNUmakefile.in b/GNUmakefile.in index 30553b2a95..27357e5e3b 100644 ---

Re: Tarball builds in the new world order

Greg Sabino Mullane writes: > On Tue, Apr 23, 2024 at 6:06 PM Tom Lane wrote: >> Now, if we just do it exactly like that >> then trying to "make dist" without setting PG_COMMIT_HASH will >> fail, since "git archive" has no default for its >> argument. I can't quite decide if that's a good

Re: Tarball builds in the new world order

Peter Eisentraut writes: > On 24.04.24 00:05, Tom Lane wrote: >> # Export the selected git ref >> git archive ${gitref} | tar xf - -C pgsql > Where does ${gitref} come from? Why doesn't this line use git archive > HEAD | ... ? ${gitref} is an argument to the script, specifying the commit to

Re: Tarball builds in the new world order

On 24.04.24 00:05, Tom Lane wrote: It makes tarballs all right, but whatever commit ID you specify is semi-ignored, and you get a tarball corresponding to HEAD of master. (The PDFs come from the right version, though!) The reason for that is that the mk-one-release script does this (shorn of

Re: Tarball builds in the new world order

On Tue, Apr 23, 2024 at 6:06 PM Tom Lane wrote: > This change seems like a good thing anyway for anyone who's tempted > to use "make dist" manually, since they wouldn't necessarily want > to package HEAD either. Now, if we just do it exactly like that > then trying to "make dist" without

Tarball builds in the new world order

With one eye on the beta-release calendar, I thought it'd be a good idea to test whether our tarball build script works for the new plan where we'll use "git archive" instead of the traditional process. It doesn't. It makes tarballs all right, but whatever commit ID you specify is semi-ignored,