Re: [RFC] building postgres with meson

Hi,

On 2022-06-01 12:39:50 +0300, Aleksander Alekseev wrote:
> > > ```
> > > ../src/include/parser/kwlist.h:332:25: error: ‘PARAMETER’ undeclared here (not
> > > in a function)
> > > 332 | PG_KEYWORD("parameter", PARAMETER, UNRESERVED_KEYWORD, BARE_LABEL)
> > >
> > > ../src/interfaces/ecpg/preproc/keywords.c:32:55: note: in definition of macro
> > > ‘PG_KEYWORD’
> > > 32 | #define PG_KEYWORD(kwname, value, category, collabel) value,
> > > ```
> >
> > Huh. I've not seen this before - could you provide a bit more detail about
> > what you did? CI isn't testing ubuntu, but it is testing Debian, so I'd expect
> > this to work.
> 
> I used PIP to install Meson, since the default APT package is too old, v0.53:
> 
> $ pip3 install --user meson
> $ meson --version
> 0.62.1
> $ ninja --version
> 1.10.0
> 
> The branch was checked out as it was described in the first email.
> Then to reproduce the issue:
> 
> $ git status
> On branch meson
> Your branch is up to date with 'andres/meson'.
> $ git fetch andres
> $ git rebase -i andres/meson
> $ meson setup build --buildtype debug
> $ cd build
> $ ninja
> 
> This is pretty much the default Ubuntu 20.04.4 LTS system with all the
> recent updates installed, so it shouldn't be a problem to reproduce
> the issue with a VM.

Will test.


> > > On MacOS I got multiple errors regarding LDAP:
> >
> > Ah, yes. Sorry, that's an open issue that I need to fix. -Dldap=disabled for
> > the rescue.  There's some crazy ordering dependency in macos framework
> > headers. The ldap framework contains an "ldap.h" header that includes
> > "ldap.h". So if you end up with the framework on the include path, you get
> > endless recursion.
> 
> Thanks, this helped.

Cool. I think I pushed a fix/workaround for the issue now. Still can't decide
whether it's apple's or meson's fault.


> I did the following:
> 
> $ meson configure -Dldap=disabled
> $ meson configure -Dssl=openssl
> $ meson configure -Dprefix=/Users/eax/pginstall

FYI, you can set multiple options in one go ;)


> ... and it terminated successfully. I was also able to configure and
> run Postgres instance using my regular scripts, with some
> modifications [1]

Cool.


> Then I decided to compile TimescaleDB against the newly installed
> Postgres. Turns out there is a slight problem.
> 
> The extension uses CMake and also requires PostgreSQL to be compiled
> with OpenSSL support. CMakeLists.txt looks for a
> "--with-(ssl=)?openssl" regular expression in the "pg_config
> --configure" output. The output is empty although Postgres was
> compiled with OpenSSL support.

Makes sense. Currently we don't fill the --configure thing, because there
configure wasn't used. We could try to generate something compatible from
meson options, but I'm not sure that's a good plan.



> The full output of pg_config looks like
> this:
> 
> ```
> CONFIGURE =
> CC = not recorded
> CPPFLAGS = not recorded
> CFLAGS = not recorded
> CFLAGS_SL = not recorded
> ... etc ...
> ```
> 
> I get a bunch of errors from the compiler if I remove this particular
> check from CMakeLists, but I have to investigate these a bit more
> since the branch is based on PG15 and we don't officially support PG15
> yet. It worked last time we checked a month or so ago, but the
> situation may have changed.

I suspect the errors might be due to CC/CPPFLAGS/... not being defined. I can
try to make it output something roughly compatible with the old output, for
most of those I already started to compute values for the PGXS compat stuff I
was hacking on recently.

Greetings,

Andres Freund