Обсуждение: 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

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