On Wed Jan 24, 2024 at 11:57 AM CST, Tristan Partin wrote:
On Wed Jan 24, 2024 at 10:18 AM CST, Tristan Partin wrote:
> On Tue Jan 23, 2024 at 3:30 AM CST, Peter Eisentraut wrote:
> > On 22.01.24 21:04, Tristan Partin wrote:
> > 3. Meson does not support tar.bz2 archives.
Submitted
On Tue Mar 26, 2024 at 2:56 AM CDT, Andres Freund wrote:
Hi,
On 2024-03-26 08:36:58 +0100, Peter Eisentraut wrote:
> On 26.03.24 01:23, Andres Freund wrote:
> > On 2024-03-25 06:44:33 +0100, Peter Eisentraut wrote:
> > > Done and committed.
> >
> > This triggered a new warning for me:
> >
> >
Hi,
On 2024-03-26 08:36:58 +0100, Peter Eisentraut wrote:
> On 26.03.24 01:23, Andres Freund wrote:
> > On 2024-03-25 06:44:33 +0100, Peter Eisentraut wrote:
> > > Done and committed.
> >
> > This triggered a new warning for me:
> >
> >
On 26.03.24 01:23, Andres Freund wrote:
On 2024-03-25 06:44:33 +0100, Peter Eisentraut wrote:
Done and committed.
This triggered a new warning for me:
../../../../../home/andres/src/postgresql/meson.build:3422: WARNING: Project
targets '>=0.54' but uses feature introduced in '0.55.0':
Hi,
On 2024-03-25 06:44:33 +0100, Peter Eisentraut wrote:
> Done and committed.
This triggered a new warning for me:
../../../../../home/andres/src/postgresql/meson.build:3422: WARNING: Project
targets '>=0.54' but uses feature introduced in '0.55.0': Passing
executable/found program object
On 24.03.24 16:42, Tristan Partin wrote:
You might find Meson's string formatting syntax creates a more readable
command string:
'tar.tar.bz2.command=@0@ -c'.format(bzip2.path())
And then 'install: false' is the default if you feel like leaving it out.
Otherwise, let's get this in!
Done
3 comments left that are inconsequential. Feel free to ignore.
+# Meson has its own distribution building command (meson dist), but we
+# are not using that at this point. The main problem is that the way
+# they have implemented it, it is not deterministic. Also, we want it
+# to be
On 22.03.24 18:29, Tristan Partin wrote:
On Thu Mar 21, 2024 at 3:44 AM CDT, Peter Eisentraut wrote:
Here is an updated version of this patch set.
You should add 'disabler: true' to the git find_program in Meson. If Git
doesn't exist on the system with the way your patch is currently
On Thu Mar 21, 2024 at 3:44 AM CDT, Peter Eisentraut wrote:
Here is an updated version of this patch set.
You should add 'disabler: true' to the git find_program in Meson. If Git
doesn't exist on the system with the way your patch is currently
written, the targets would be defined, even
Here is an updated version of this patch set.
I have removed the "dirty check" stuff. It didn't really work well/was
buggy under meson, and it failed mysteriously on the Linux CI tasks. So
let's just drop that functionality for now.
I have also added a more complete commit message and some
On 12.02.24 18:26, Tristan Partin wrote:
On Sun Feb 11, 2024 at 5:09 PM CST, Peter Eisentraut wrote:
Small update: I noticed that on Windows (at least the one that is
running the CI job), I need to use git -c core.autocrlf=false,
otherwise git archive does line-ending conversion for the files
On Sun Feb 11, 2024 at 5:09 PM CST, Peter Eisentraut wrote:
Small update: I noticed that on Windows (at least the one that is
running the CI job), I need to use git -c core.autocrlf=false, otherwise
git archive does line-ending conversion for the files it puts into the
archive. With this fix,
Small update: I noticed that on Windows (at least the one that is
running the CI job), I need to use git -c core.autocrlf=false, otherwise
git archive does line-ending conversion for the files it puts into the
archive. With this fix, all the archives produced by all the CI jobs
across the
On Wed, Jan 31, 2024 at 10:50 AM Eli Schwartz wrote:
> Ideally git commits should be signed, but that requires large numbers of
> people to have security-minded git commit habits. From a quick check of
> the postgres commit logs, only one person seems to be regularly signing
> commits, which does
On 1/31/24 3:03 AM, Peter Eisentraut wrote:
>> What do you use this for? IMO a more robust way to track the commit used
>> is to use gitattributes export-subst to write a `.git_archival.txt` file
>> containing the commit sha1 and other info -- this can be read even after
>> the file is extracted,
On 26.01.24 22:18, Eli Schwartz wrote:
Hello, meson developer here.
Hello, and thanks for popping in!
3. Meson does not support tar.bz2 archives.
Simple enough to add, but I'm a bit surprised as usually people seem to
want either gzip for portability or xz for efficient compression.
We
Hello, meson developer here.
On 1/23/24 4:30 AM, Peter Eisentraut wrote:
> On 22.01.24 21:04, Tristan Partin wrote:
>> I am not really following why we can't use the builtin Meson dist
>> command. The only difference from my testing is it doesn't use a
>> --prefix argument.
>
> Here are some
On Fri Jan 26, 2024 at 12:28 AM CST, Peter Eisentraut wrote:
On 25.01.24 17:25, Tristan Partin wrote:
> 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.
On 25.01.24 17:25, Tristan Partin wrote:
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.
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
On 22.01.24 21:04, Tristan Partin wrote:
+git = find_program('git', required: false, native: true, disabler: true)
+bzip2 = find_program('bzip2', required: false, native: true,
disabler: true)
This doesn't need to be a disabler. git is fine as-is. See later
comment. Disablers only work like
On 24.01.24 18:57, Tristan Partin wrote:
> 4. Meson uses git archive internally, but then unpacks and repacks
the > archive, which loses the ability to use git get-tar-commit-id.
Because Meson allows projects to distribute arbitrary files via
meson.add_dist_script(), and can include
On Wed Jan 24, 2024 at 10:18 AM CST, Tristan Partin wrote:
On Tue Jan 23, 2024 at 3:30 AM CST, Peter Eisentraut wrote:
> On 22.01.24 21:04, Tristan Partin wrote:
> > I am not really following why we can't use the builtin Meson dist
> > command. The only difference from my testing is it doesn't
On Tue Jan 23, 2024 at 3:30 AM CST, Peter Eisentraut wrote:
On 22.01.24 21:04, Tristan Partin wrote:
> I am not really following why we can't use the builtin Meson dist
> command. The only difference from my testing is it doesn't use a
> --prefix argument.
Here are some problems I have
On 22.01.24 21:04, Tristan Partin wrote:
I am not really following why we can't use the builtin Meson dist
command. The only difference from my testing is it doesn't use a
--prefix argument.
Here are some problems I have identified:
1. meson dist internally runs gzip without the -n option.
On Tue, Jan 23, 2024 at 2:36 AM Peter Eisentraut wrote:
>
> On 22.01.24 13:10, Junwang Zhao wrote:
> > I played this with meson build on macOS, the packages are generated
> > in source root but not build root, I'm sure if this is by design but I think
> > polluting *working directory* is not
On Mon Jan 22, 2024 at 1:31 AM CST, Peter Eisentraut wrote:
From 4b128faca90238d0a0bb6949a8050c2501d1bd67 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut
Date: Sat, 20 Jan 2024 21:54:36 +0100
Subject: [PATCH v0] make dist uses git archive
---
GNUmakefile.in | 34
On 22.01.24 13:10, Junwang Zhao wrote:
I played this with meson build on macOS, the packages are generated
in source root but not build root, I'm sure if this is by design but I think
polluting *working directory* is not good.
Yes, it's not good, but I couldn't find a way to make it work.
Hi,
On Mon, Jan 22, 2024 at 3:32 PM Peter Eisentraut wrote:
>
> One of the goals is to make the creation of the distribution tarball
> more directly traceable to the git repository. That is why we removed
> the "make distprep" step.
>
> Here I want to take another step in that direction, by
One of the goals is to make the creation of the distribution tarball
more directly traceable to the git repository. That is why we removed
the "make distprep" step.
Here I want to take another step in that direction, by changing "make
dist" to directly use "git archive", rather than the
30 matches
Mail list logo
