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 note

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 equivale

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 , whic

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 w

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 > +# (T

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 --- a/G

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 thing

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 be

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 no

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 setting