Re: [RFC] building postgres with meson - v12

From: Andres Freund <andres(at)anarazel(dot)de>
To: John Naylor <john(dot)naylor(at)enterprisedb(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, samay sharma <smilingsamay(at)gmail(dot)com>, Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>
Subject: Re: [RFC] building postgres with meson - v12
Date: 2022-09-02 16:35:15
Message-ID: 20220902163515.vonnesmbu6lsissq@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2022-09-02 14:17:26 +0700, John Naylor wrote:
> On Thu, Sep 1, 2022 at 1:12 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > [v12]
>
> +# Build a small utility static lib for the parser. This makes it easier to not
> +# depend on gram.h already having been generated for most of the other code
> +# (which depends on generated headers having been generated). The generation
> +# of the parser is slow...
>
> It's not obvious whether this is intended to be a Meson-only
> optimization or a workaround for something awkward to specify.

It is an optimization. The parser generation is by far the slowest part of a
build. If other files can only be compiled once gram.h is generated, there's a
long initial period where little can happen. So instead of having all .c files
have a dependency on gram.h having been generated, the above makes only
scan.c, gram.c compilation depend on gram.h. It only matters for the first
compilation, because such dependencies are added as order-only dependencies,
supplanted by more precise compiler generated dependencies after.

See the attached dep and nodep.png. That's ui.perfetto.dev displaying the
.ninja_log file, showing the time for building the backend on my
workstation. The difference is probably apparent.

It's still pretty annoying that so much of the build is initially idle,
waiting for genbki.pl to finish.

Part of that is due to some ugly dependencies of src/common on backend headers
that IMO probably shouldn't exist (e.g. src/common/relpath.c includes
catalog/pg_tablespace_d.h). Looks like it'd not be hard to get at least the
_shlib version of src/common and libpq build without waiting for that. But for
all the backend code I don't really see a way, so it'd be nice to make genbki
faster at some point.

> + # FIXME: -output option is only available in perl 5.9.3 - but that's
> + # probably a fine minimum requirement?
>
> Since we've retired some buildfarm animals recently, it seems the
> oldest perl there is 5.14? ... which came out in 2011, so it seems
> later on we could just set that as the minimum.

At the moment we document 5.8.3 as our minimum, supposedly based on some
buildfarm animal - but that's probably outdated. Perhaps time to start that
discussion? Or maybe it's fine to just have the meson stuff have that
dependency for now. Seems exceedingly unlikely anybody would care.

Greetings,

Andres Freund

Attachment Content-Type Size
dep.png image/png 820.3 KB
nodep.png image/png 934.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2022-09-02 16:57:23 Re: [RFC] building postgres with meson - v12
Previous Message Zhihong Yu 2022-09-02 16:13:39 Re: On login trigger: take three