Re: make dist using git archive

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)

In response to

Responses

Browse pgsql-hackers by date

  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