From: | "Tristan Partin" <tristan(at)neon(dot)tech> |
---|---|
To: | "Peter Eisentraut" <peter(at)eisentraut(dot)org> |
Cc: | "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: make dist using git archive |
Date: | 2024-01-25 16:25:19 |
Message-ID: | CYNXE6A4IB2S.V1YYOX54IVJ@neon.tech |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu Jan 25, 2024 at 10:04 AM CST, Peter Eisentraut wrote:
> On 22.01.24 21:04, Tristan Partin wrote:
> >> + 'HEAD', '.'],
> >> + install: false,
> >> + output: distdir + '.tar.bz2',
> >> +)
> >
> > The bz2 target should be wrapped in an `if bzip2.found()`.
The way that this currently works is that you will fail at configure
time if bz2 doesn't exist on the system. Meson will try to resolve
a .path() method on a NotFoundProgram. You might want to define the bz2
target to just call `exit 1` in this case.
if bzip2.found()
# do your current target
else
bz2 = run_target('tar.bz2', command: ['exit', 1])
endif
This should cause pgdist to appropriately fail at run time when
generating the bz2 tarball.
> Well, I think we want the dist step to fail if bzip2 is not there. At
> least that is the current expectation.
>
> >> +alias_target('pgdist', [check_dirty_index, tar_gz, tar_bz2])
> >
> > Are you intending for the check_dirty_index target to prohibit the other
> > two targets from running? Currently that is not the case.
>
> Yes, that was the hope, and that's how the make dist variant works. But
> I couldn't figure this out with meson. Also, the above actually also
> doesn't work with older meson versions, so I had to comment this out to
> get CI to work.
>
> > If it is what
> > you intend, use a stamp file or something to indicate a relationship.
> > Alternatively, inline the git diff-index into the other commands. These
> > might also do better as external scripts. It would reduce duplication
> > between the autotools and Meson builds.
>
> Yeah, maybe that's a direction.
For what it's worth, I run Meson 1.3, and the behavior of generating the
tarballs even though it is a dirty tree still occurred. In the new patch
you seem to say it was fixed in 0.60.
--
Tristan Partin
Neon (https://neon.tech)
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2024-01-25 16:33:43 | Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock |
Previous Message | Alvaro Herrera | 2024-01-25 16:22:07 | Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock |