Re: Documentation for building with meson

Hi,

On 2022-12-01 15:58:39 +0100, Peter Eisentraut wrote:
> On 23.11.22 22:24, samay sharma wrote:
> > Thank you. Attaching v7 addressing most of the points below.
>
> I have committed this, after some editing and making some structural
> changes.

Thanks. I was working on that too, but somehow felt a bit stuck...

I'll try if I can adapt my pending changes.

> I moved the "Requirements" section back to the top level. It did
> not look appealing to have to maintain two copies of this that have almost
> no substantial difference (but for some reason were written with separate
> structure and wording).

I don't think this is good. The whole "The following software packages are
required for building PostgreSQL" section is wrong now. "They are not
required in the default configuration, but they are needed when certain build
options are enabled, as explained below:" section is misleading as well.

By the time we fix all of those we'll end up with a different section again.

> Also, I rearranged the Building with Meson section to use the same internal
> structure as the Building with Autoconf and Make section. This will make it
> easier to maintain going forward. For example if someone adds a new option,
> it will be easier to find the corresponding places in the lists where to add
> them.

I don't know. The existing list order makes very little sense to me. The
E.g. --enable-nls is before the rest in configure, presumably because it sorts
there alphabetically. But that's not the case for meson.

Copying "Anti-Features" as a structure element to the meson docs seems bogus
(also the name is bogus, but that's a pre-existing issue). There's no
difference in -Dreadline= to the other options meson-options-features list.

Nor does -Dspinlocks= -Datomics= make sense in the "anti features" section. It
made some sense for autoconf because of the --without- prefix, but that's not
at play in meson. Their placement in the "Developer Options" made a whole lot
more sense.

I don't like "Miscellaneous" bit containing minor stuff like krb_srvnam and
data layout changing options like blocksize,segsize,wal_blocksize. But it
makes sense to change that for both at the same time.

> We will likely keep iterating on the contents for the next little while, but
> I'm glad we now have a structure in place that we should be able to live
> with.

I agree that it's good to have something we can work from more
iteratively. But I don't think this is a structure that we can live with.

I'm not particularly happy about this level of structural change made without
discussing it prior.

Greetings,

Andres Freund