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-26T21:15:35Z
Lists: pgsql-hackers 
On Mon, Sep 26, 2022 at 1:27 PM Andres Freund <andres@anarazel.de> wrote:
> > 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?
>
> Yes. The only caveat is that it makes lines longer, because it's included in
> the printed test line (there's no real requirement to have the test suite and
> the setup named the same,b ut it seems confusing not to)

Probably doesn't have to be too long. And I'm not sure of the details.
Just a small thing from my point of view.

> > * 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?
>
> You can use --print-errorlogs to print the log output iff a test fails. It's a
> bit painful that some tests have very verbose output :(.  I don't really see a
> way that meson can help us here, this is pretty much on "our" end.

Makes sense. Thanks.

> Hm. I'm not entirely sure what you mean here. The only thing that you can't
> change in a existing build-dir with meson configure is the compiler.

I do understand that it doesn't particularly matter to meson itself.
The point I was making was one about how I personally find it
convenient to set those things that I know will never change in
practice (because they're fundamentally things that I know that I
won't ever need to change) during "meson setup", while doing
everything else using "meson configure". I like to automate everything
using shell scripts. I will very occasionally have to run "meson
setup" via a zsh function anyway, so why not couple that process with
the process of setting "immutable for this build directory" settings?

With autoconf, I will run one of various zsh functions that run
configure in some specific way -- there are various "build types",
such as debug, release, and Valgrind. But with meson it makes sense to
split it in two -- have a generic zsh function for generic once-off
build directory setup (including even the mkdir), that also sets
generic, "immutable" settings, and a specialized zsh function that
changes things in a way that is particular to that kind of build (like
whether asserts are enabled, optimization level, and so on).

> I personally have different types of build dirs set up in parallel
> (e.g. assert, optimize, assert-32, assert-w64). I'll occasionally
> enable/disable

I know that other experienced hackers do it that way. I have found
that ccache works well enough that I don't feel the need for multiple
build directories per branch.

Perhaps I've assumed more than I should about my approach being
broadly representative. It might ultimately be easier to just have
multiple build directories per branch/source directory -- one per
"build type" per branch. That has the advantage of not requiring each
"build type" zsh function to remember to reset anything that might
have been set by one of its sibling zsh functions for some other build
type (there is no need to "reset the setting to its default"). That
approach is more like scripting autoconf/configure would be, in that
you basically never change any settings for a given build directory in
practice (you maybe invent a new kind of build type instead, or you
update the definition of an existing standard build type based on a
new requirement for that build type).

It's really handy that meson lets you quickly change one setting
against an existing build directory. I'm slightly worried that that
will allow me to shoot myself in the foot, though. Perhaps I'll change
some exotic setting in an ad-hoc way, and then forget to unset it
afterwards, leading to (say) a mysterious performance degradation for
what is supposed to be one of my known standard build types. There is
no risk of that with my autoconf/configure workflow, because I'll
rerun the relevant configure zsh function before long anyway, making
it impossible for me to accidentally keep something that I never meant
to keep.

I like being able to throw everything away and quickly rebuild "from
scratch" (in reality rebuild using ccache and a cache for configure)
due to superstition/defensive paranoia/learned helplessness. This has
always worked well enough because ccache works fairly well. I'm not
sure how useful that kind of mindset will be with meson just yet, and
if I'm just thinking about it in the wrong way, so forgive me for
rambling like this.

-- 
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