Hi,
On Tue, 28 Oct 2025 at 07:19, Michael Paquier wrote:
>
> Another less invasive solution for the code tree would be to have
> meson cross-check that the list of files it defines matches with
> what's on disk. With the drop of Makefiles and ./configure at some
> point in mind, I am not convinc
On 2025-Oct-28, Michael Paquier wrote:
> IMO, we should tackle this problem the other way around: what would it
> take to have meson build a list of the TAP files in t/ based on an
> automated rule when tests.tap is defined?
Maybe what we need is a single source of truth that is used both by
Make
On Fri, Oct 24, 2025 at 10:49:53AM -0500, Nathan Bossart wrote:
> On Sat, Aug 23, 2025 at 10:17:59AM -0400, Tom Lane wrote:
>> This proposed fix adds more manual maintenance effort, and I really
>> doubt that it will do much to solve the ostensible problem that
>> people forget to update the meson.
On Sat, Aug 23, 2025 at 10:17:59AM -0400, Tom Lane wrote:
> This proposed fix adds more manual maintenance effort, and I really
> doubt that it will do much to solve the ostensible problem that
> people forget to update the meson.build files.
This was my reaction, too. I suspect folks will update
On 23.08.25 08:09, Peter Eisentraut wrote:
meson.build files have to list TAP test files explicitly. Makefiles
have been relying on a t/*.pl wildcard. As a consequence, it is
traditional now that many developers who are primarily using make forget
to add any new TAP test files to the respecti
On 2025-Aug-25, Andres Freund wrote:
> Unless somebody else volunteers (please!), I guess I should write up a
> patch...
Maybe it doesn't have to be a patch -- we have some info on command
lines to use for testing at
https://wiki.postgresql.org/wiki/Meson#Test_related_commands
which can perhaps b
Hi,
On 2025-08-23 12:11:51 -0400, Tom Lane wrote:
> Andres Freund writes:
> > FWIW, I find the autoconf/make test run experience completely unusable. It
> > literally is made me embark on getting away from it. I don't understand how
> > people stand it.
>
> Interesting perspective, because from w
Andres Freund writes:
> FWIW, I find the autoconf/make test run experience completely unusable. It
> literally is made me embark on getting away from it. I don't understand how
> people stand it.
Interesting perspective, because from where I sit the testing aspect
is the weakest part of our meson
On 2025-08-23 Sa 10:38 AM, Andres Freund wrote:
Hi,
On 2025-08-23 10:17:59 -0400, Tom Lane wrote:
We should be striving to make the meson system as easy to use as
autoconf/make, not trying to attain parity by making the latter experience
worse.
FWIW, I find the autoconf/make test run experi
Hi,
On 2025-08-23 10:17:59 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2025-08-23 11:57:37 +0500, Andrey Borodin wrote:
> >> What is the downside of the approach where meson uses t/*.pl wildcard?
>
> > In meson you can't do wildcards at "configure" time, since wildcards do not
> > allo
Andres Freund writes:
> On 2025-08-23 11:57:37 +0500, Andrey Borodin wrote:
>> What is the downside of the approach where meson uses t/*.pl wildcard?
> In meson you can't do wildcards at "configure" time, since wildcards do not
> allow reliable detection of when re-configure is needed.
But ... w
Hi,
On 2025-08-23 11:57:37 +0500, Andrey Borodin wrote:
> I agree that this difference between meson and autotools builds is kind of
> problematic.
>
> > On 23 Aug 2025, at 11:09, Peter Eisentraut wrote:
> >
> > The obvious solution is to also require the makefiles to list TAP files
> > expli
I agree that this difference between meson and autotools builds is kind of
problematic.
> On 23 Aug 2025, at 11:09, Peter Eisentraut wrote:
>
> The obvious solution is to also require the makefiles to list TAP files
> explicitly, which is what I'm proposing here.
What is the downside of the a
13 matches
Mail list logo
