meson: Non-feature feature options

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: meson: Non-feature feature options
Date: 2023-02-08 10:45:05
Message-ID: ad65ffd1-a9a7-fda1-59c6-f7dc763c3051@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Most meson options (meson_options.txt) that enable an external
dependency (e.g., icu, ldap) are of type 'feature'. Most of these have
a default value of 'auto', which means they are pulled in automatically
if found. Some have a default value of 'disabled' for specific reasons
(e.g., selinux). This is all good.

Two options deviate from this in annoying ways:

option('ssl', type : 'combo', choices : ['none', 'openssl'],
value : 'none',
description: 'use LIB for SSL/TLS support (openssl)')

option('uuid', type : 'combo', choices : ['none', 'bsd', 'e2fs', 'ossp'],
value : 'none',
description: 'build contrib/uuid-ossp using LIB')

These were moved over from configure like that.

The problem is that these features now cannot be automatically enabled
and behave annoyingly different from other feature options.

For the 'ssl' option, we have deprecated the --with-openssl option in
configure and replaced it with --with-ssl, in anticipation of other SSL
implementations. None of that ever happened or is currently planned
AFAICT. So I suggest that we semi-revert this, so that we can make
'openssl' an auto option in meson.

For the 'uuid' option, I'm not sure what the best way to address this
would. We could establish a search order of libraries that is used if
no specific one is set (similar to libreadline, libedit, in a way). So
we'd have one option 'uuid' that is of type feature with default 'auto'
and another option, say, 'uuid-library' of type 'combo'.

Thoughts?

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2023-02-08 10:49:00 Re: A bug with ExecCheckPermissions
Previous Message Tomas Vondra 2023-02-08 10:42:45 Re: Performance issues with parallelism and LIMIT