meson uses stale pg_config_paths.h left over from make
I've been having some problems running the regression tests using
meson on Windows. This seems to be down to initdb being compiled with
a version of pg_config_paths.h left over from the msvc build which had
been used on that source tree previously.
Generally when there are files left over the meson build script will
detect this and ask you to run make maintainer-clean. That's useful
on Linux, but on Windows you're just left to manually remove the
conflicting files which are listed. Unfortunately, pg_config_paths.h
wasn't listed, which I think was missed because it's not generated
during configure, but during the actual make build. (see
src/port/Makefile)
Linux users are unlikely to experience this issue as they're likely
just going to run make maintainer-clean as instructed by the meson
error message.
The attached patch adds pg_config_paths.h to the generated_sources_ac
variable so that if that file exists, meson will provide an error
message to mention this. i.e:
meson.build:2953:2: ERROR: Problem encountered:
****
Non-clean source code directory detected.
To build with meson the source tree may not have an in-place, ./configure
style, build configured. You can have both meson and ./configure style builds
for the same source tree by building out-of-source / VPATH with
configure. Alternatively use a separate check out for meson based builds.
Conflicting files in source directory:
C:/Users/<user>/pg_src/src/port/pg_config_paths.h
The conflicting files need to be removed, either by removing the files listed
above, or by running configure and then make maintainer-clean.
Are there any objections to the attached being applied?
David
Attachments:
pg_config_paths_meson.patchapplication/octet-stream; name=pg_config_paths_meson.patchDownload
diff --git a/src/port/meson.build b/src/port/meson.build
index deb354418d..a0d0a9583a 100644
--- a/src/port/meson.build
+++ b/src/port/meson.build
@@ -195,3 +195,6 @@ endforeach
pgport_srv = pgport['_srv']
pgport_static = pgport['']
pgport_shlib = pgport['_shlib']
+
+# autoconf generates the file there, ensure we get a conflict
+generated_sources_ac += {'src/port': ['pg_config_paths.h']}
On Thu, 24 Aug 2023 at 00:52, David Rowley <dgrowleyml@gmail.com> wrote:
Are there any objections to the attached being applied?
Pushed.
David
On 23.08.23 14:52, David Rowley wrote:
Generally when there are files left over the meson build script will
detect this and ask you to run make maintainer-clean. That's useful
on Linux, but on Windows you're just left to manually remove the
conflicting files which are listed. Unfortunately, pg_config_paths.h
wasn't listed, which I think was missed because it's not generated
during configure, but during the actual make build. (see
src/port/Makefile)
How is this different from any other built file being left in the tree?
Surely meson should not be required to detect that?
Hi,
On 2023-08-24 08:18:14 +0200, Peter Eisentraut wrote:
On 23.08.23 14:52, David Rowley wrote:
Generally when there are files left over the meson build script will
detect this and ask you to run make maintainer-clean. That's useful
on Linux, but on Windows you're just left to manually remove the
conflicting files which are listed. Unfortunately, pg_config_paths.h
wasn't listed, which I think was missed because it's not generated
during configure, but during the actual make build. (see
src/port/Makefile)How is this different from any other built file being left in the tree?
Files included into other files (i.e. mostly .h, but also a few .c) are
particularly problematic, because they will be used from the source tree, if
the #include doesn't have directory component - the current directory will
always be searched first. In this case initdb on David's machine failed,
because the paths from the wrong pg_config_paths.h was used.
Surely meson should not be required to detect that?
I think we should try to detect included files, due to the nasty and hard to
debug issues that creates. I've spent quite a bit of time helping people to
debug such issues.
Greetings,
Andres Freund
On Thu, 24 Aug 2023 at 18:25, Andres Freund <andres@anarazel.de> wrote:
On 2023-08-24 08:18:14 +0200, Peter Eisentraut wrote:
Surely meson should not be required to detect that?
I think we should try to detect included files, due to the nasty and hard to
debug issues that creates. I've spent quite a bit of time helping people to
debug such issues.
Yeah, I agree. I think it's a fairly trivial thing to do to help avoid
developers spending hours scratching their heads over some
hard-to-debug meson issue.
I think lowering the difficulty bar for people transitioning to meson
is a good thing. The easier we can make that process, the faster
people will adopt meson and the faster we can get rid of support for
the other build systems. That's likely not too far off into the
distant future for MSVC, so I don't think we should go rejecting
patches from people using that build system where the patch aims to
help that transition go faster and more smoothly.
David