Horton

Re: [RFC] building postgres with meson - v13

Peter Geoghegan <pg@bowt.ie>

View thread View on postgr.es
From: Peter Geoghegan <pg@bowt.ie>
To: Andres Freund <andres@anarazel.de>
Cc: Nathan Bossart <nathandbossart@gmail.com>, Andrew Dunstan <andrew@dunslane.net>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, Tom Lane <tgl@sss.pgh.pa.us>, Thomas Munro <thomas.munro@gmail.com>, Justin Pryzby <pryzby@telsasoft.com>, samay sharma <smilingsamay@gmail.com>, Nazir Bilal Yavuz <byavuz81@gmail.com>, pgsql-hackers@postgresql.org
Date: 2022-09-26T19:47:14Z
Lists: pgsql-hackers 
On Sun, Sep 25, 2022 at 5:38 PM Andres Freund <andres@anarazel.de> wrote:
> # run just the main pg_regress tests against existing server
> meson test --setup running main/regress-running

> Peter, would this address your use case?

I tried out your v16 patchset, which seems to mostly work as I'd hoped
it would. Some feedback:

* I gather that "running" as it appears in commands like "meson test
--setup running" refers to a particular setup named "running", that
you invented as part of creating a meson-ish substitute for
installcheck. Can "running" be renamed to something that makes it
obvious that it's a Postgres thing, and not a generic meson thing?

Maybe some kind of consistent naming convention would work best here.
This setup could be "pg_against_running_server", or something along
those lines.

* It would be nice if failed tests told me exactly which "diffs" file
I needed to look at, without my having to look for the message through
the meson log (or running with -v). Is this possible?

To be fair I should probably just be running -v when I run tests
against an existing running server, anyway -- so maybe I'm asking for
the wrong thing. It would at least be slightly better if I always got
to see a path to a .diffs file for failed tests, even without -v. But
it's just a "nice to have" thing -- it's not worth going out of your
way to make it work like that

* Just FYI, there are considerations about the libpq that we link to
here (actually this isn't particularly related to the new installcheck
work, but thought I'd mention it in passing).

I'm using Debian Unstable here. Like Nathan, I found that I needed a
custom -Dextra_lib_dirs just so that binaries would link against the
installation's own libpq, rather than the system libpq. This is
important-ish because linking to the wrong libpq means that I get an
error about not being able to connect via trust authentication to a
unix socket from the directory /var/run/postgresql -- confusion over
where to look for sockets visibly breaks many things.

The workaround that I have is fine, but this still seems like
something that should "just work". I believe that there is a pending
patch for this already, so enough said here.

> I think it'd make sense to add a few toplevel targets to run tests in certain
> ways, but I've not done that here.

I usually run "installcheck-world" (not just installcheck) when I want
to do a generic smoke test with Vaglrind. Sometimes that will fail
relatively early for very silly reasons, for example because I don't
have exactly the expected plan in some harmless way (I try to account
for this by running Valgrind in a shellscript that tries to match
"make check", but that doesn't always work). It is nice that I won't
have to worry about such minor issues derailing everything for a long
running and unsupervised Valgrind test. (Maybe I could have worked
around this before now, but I guess I never tried.)

More generally, I think that we should be encouraging users to think
of the tests as something that you can run in any order. People should
be encouraged to think in terms of the meson abstractions, such as
test setups.

I found that "meson test --setup running --list" will show me what
tests I'll be running if I want to do "installcheck" style testing,
without having to run any tests at all -- another small but important
improvement. This seems worth drawing attention to on the meson Wiki
page as a non-obvious improvement over "installcheck". I might even
find it useful to hard-code some of these tests in a shellscript, that
runs only a subset of "--setup running" tests that happen to be
interesting for Valgrind testing right now.

BTW the meson wiki page iencourages users to think of "meson setup"
and "meson configure" as equivalent to autoconf configure. I get why
you explained it like that, but that confused me at first. What I
since figured out (which will be absurdly obvious to you) is that you
really need to decouple the generic from the specific -- very much
unlike autoconf. I found it useful to separate stuff that I know will
never change for a given build directory (such as the prefix install
path) from other things that are variable configuration settings
(things like the optimization level used by GCC). I now have a
scripted way of running "meson setup" for the former stuff (which is
generic), and a scripted way of running "meson configure" for the
latter set of stuff (with variations for "standard" release and debug
builds, building Valgrind, etc).

-- 
Peter Geoghegan

Commits

  1. meson: Add 'running' test setup, as a replacement for installcheck

  2. meson: Add support for building with precompiled headers

  3. windows: Adjust FD_SETSIZE via commandline define

  4. meson: docs: Add xml{lint,proc} wrapper to collect dependencies

  5. meson: ecpg: Split definition of static and shared libraries

  6. windows: Set UMDF_USING_NTSTATUS globally, include ntstatus.h

  7. ci: Add hint about downloadable logs to README

  8. meson: Set up absolute rpaths to libdir

  9. meson: Include CFLAGS/c_args in summary and pg_config output

  10. windows: remove date from version number in win32ver.rc

  11. meson: Add initial version of meson based build system

  12. ci: windows: set error mode to not include SEM_NOGPFAULTERRORBOX

  13. Refactor PG_TEST_EXTRA logic in autoconf build

  14. Split TESTDIR into TESTLOGDIR and TESTDATADIR

  15. Don't hardcode tmp_check/ as test directory for tap tests

  16. Extend gendef.pl in preparation for meson

  17. Include c.h instead of postgres.h in src/port/*p{read,write}*.c

  18. Remove DLLTOOL, DLLWRAP from configure / Makefile.global.in

  19. Run xmllint validation only once

  20. Bump minimum Perl version to 5.14

  21. Move gramparse.h to src/backend/parser

  22. Run perltidy over Catalog.pm

  23. Parse catalog .dat files as a whole when compiling the backend

  24. Build all Flex files standalone

  25. Move private declarations shared between guc.c and guc-file.l to new header

  26. Preparatory refactoring for compiling guc-file.c standalone

  27. Move darwin sysroot determination into separate file

  28. Fix MSVC warning in compat_informix/rnull.pgc

  29. solaris: Use versioning scripts instead of -Bsymbolic

  30. Change shared library installation naming on macOS

  31. regress: allow to specify directory containing expected files, for ecpg

  32. Don't add HAVE_LDAP_H HAVE_WINLDAP_H to pg_config.h

  33. Refactor dtrace postprocessing make rules

  34. Add output directory option to gen_node_support.pl

  35. Add output directory argument to generate-unicode_norm_table.pl

  36. Add output file argument to generate-errcodes.pl

  37. Add output path arg in generate-lwlocknames.pl

  38. Move snowball_create.sql creation into perl file

  39. ecpg: Output dir, source dir, stamp file argument for preproc/*.pl

  40. psql: Output dir and dependency generation for sql_help

  41. Deal with paths containing \ and spaces in basebackup_to_shell tests

  42. Remove LLVM_CONFIG from Makefile.global.in

  43. Make update-unicode target work in vpath builds

  44. Refactor DLSUFFIX handling

  45. ldap tests: Add paths for openbsd.

  46. ldap tests: Don't run on unsupported operating systems.

  47. Remove check for accept() argument types

  48. Move our p{read,write}v replacements into their own files.

  49. Adjust yywrap macro for non-reentrant scanners for MSVC.

  50. Remove any -arch switches given in ExtUtils::Embed's ldopts from our

  51. Change PL/Perl and Pg interface build to use configured compiler and

  52. Apparently, on some systems, ExtUtils::Embed and MakeMaker are slightly