Re: [RFC] building postgres with meson - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [RFC] building postgres with meson
Date
Msg-id 1064888.1654189729@sss.pgh.pa.us
Whole thread Raw
In response to Re: [RFC] building postgres with meson  (Andres Freund <andres@anarazel.de>)
Responses Re: [RFC] building postgres with meson
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> I'm not quite sure what the proper behaviour is when doing an out-of-tree
> build with meson (all builds are out-of-tree), with a pre-existing flex /
> bison output in the source tree that is out of date.

Definitely sounds like a gotcha.

On the one hand, there's been some discussion already of removing all
derived files from tarballs and just insisting that users provide all
needed tools when building from source.  If we did that, it could be
sufficient for the meson build to check that no such files are present
in the source tree.  (Checking a couple of them would be enough, likely.)

On the other hand, I'm not sure that I want such a change to be forced
by a toolchain change.  It definitely seems a bit contrary to the plan
we'd formed of allowing meson and make-based builds to coexist for
a few years, because we'd be breaking at least some make-based build
processes.

Could we have the meson build check that, say, if gram.c exists it
is newer than gram.y?  Or get it to ignore an in-tree gram.c?

            regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: convert libpq uri-regress tests to tap test
Next
From: Tom Lane
Date:
Subject: Re: replacing role-level NOINHERIT with a grant-level option