Re: [RFC] building postgres with meson - v13 - Mailing list pgsql-hackers

Hi,

On 2022-09-26 12:47:14 -0700, Peter Geoghegan wrote:
> 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.

Thanks & cool.


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


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

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.


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

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

Greetings,

Andres Freund