Re: [RFC] building postgres with meson - v13 - Mailing list pgsql-hackers
| From | samay sharma |
|---|---|
| Subject | Re: [RFC] building postgres with meson - v13 |
| Date | |
| Msg-id | CAJxrbyxSjV0G7hCGKc=Ym2q=cy3g3Gd1tukfOXZncQqetw_cRA@mail.gmail.com Whole thread Raw |
| In response to | Re: [RFC] building postgres with meson - v13 (Peter Eisentraut <peter.eisentraut@enterprisedb.com>) |
| Responses |
Re: [RFC] building postgres with meson - v13
|
| List | pgsql-hackers |
Hi,
On Mon, Sep 26, 2022 at 6:02 AM Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote:
On 24.09.22 20:09, Andres Freund wrote:
> On 2022-09-24 13:52:29 -0400, Tom Lane wrote:
>> ... btw, shouldn't the CF entry [1] get closed now?
>
> Unfortunately not - there's quite a few followup patches that haven't been
> [fully] reviewed and thus not applied yet.
Here is some review of the remaining ones (might not match exactly what
you attached, I was working off your branch):
9f789350a7a7 meson: ci: wip: move compilerwarnings task to meson
This sounds reasonable to me in principle, but I haven't followed the
cirrus stuff too closely, and it doesn't say why it's "wip". Perhaps
others could take a closer look.
ccf20a68f874 meson: ci: Add additional CI coverage
IIUC, this is just for testing your branch, not meant for master?
02d84c21b227 meson: prereq: win: remove date from version number in
win32ver.rc
do it
5c42b3e7812e meson: WIP: Add some of the windows resource files
What is the thinking on this now? What does this change over the
current state?
9bc60bccfd10 meson: Add support for relative rpaths, fixing tests on
MacOS w/ SIP
I suggest a separate thread and/or CF entry for this. There have been
various attempts to deal with SIP before, with varying results. This
is not part of the meson transition as such.
9f5be26c1215 meson: Add docs for building with meson
I do like the overall layout of this.
The "Supported Platforms" section should be moved back to near the end
of the chapter. I don't see a reason to move it forward, at least
none that is related to the meson issue.
Agreed that it's unrelated to meson. However, I think it's better to move it in the front as it's generally useful to know if your platform is supported before you start performing the installation steps and get stuck somewhere.
Do you think I should submit that as a separate commit in the same patch-set or just move it out to a completely different patch submission?
The changes to the "Getting the Source" section are also not
appropriate for this patch.
Given that many developers are now using Git for downloading the source code, I think it makes sense to be in the Getting the source section. Also, meson today doesn't cleanly build via the tarballs. Hence, I added it to the section (and patchset).
Do you think I should move this to a different patch?
In the section "Building and Installation with meson":
- Remove the "git clone" stuff.
- The "Running tests" section should be moved to Chapter 33. Regression
Tests.
The autoconf / make section also has a small section on how to run the regression tests. The "Running tests" section is meant to the be equivalent of that for meson (i.e. brief overview). I do intend to add a detailed section to Chapter 33 with more info on how to interpret test results etc. Do you think the current section is too verbose for where it is?
Some copy-editing will probably be suitable, but I haven't focused on
that yet.
9c00d355d0e9 meson: Add PGXS compatibility
This looks like a reasonable direction to me. How complete is it? It
says it works for some extensions but not others. How do we define
the target line here?
3fd5e13dcad3 meson: Add postgresql-extension.pc for building extension
libraries
Separate thread for this as well. This is good and important, but we
must also add it to the make build.
4b5bfa1c19aa meson: Add LLVM bitcode emission
still in progress
eb40f6e53104 meson: Add support for building with precompiled headers
Any reason not to enable this by default? The benefits on non-Windows
appear to be less dramatic, but they are not zero. Might be better to
enable it consistently so that for example any breakage is easier
caught.
377bfdea6042 meson: Add xmllint/xsltproc wrapper script to handle
dependencies automatically
Is this part of the initial transition, required for correctness, or
is it an optional optimization? Could use more explanation. Maybe
move to separate thread also?
pgsql-hackers by date: