Thread: 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
Attachment
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