Thread: meson "experimental"?
In installation.sgml it says """ Alternatively, PostgreSQL can be built using Meson. This is currently experimental. """ Do we want to alter this statement for PG17, considering that this is now the only way to build for Windows using MSVC? (A joke response is that the Windows port itself is experimental, so it doesn't matter much that the build system for it is as well.) I would still call Meson use on non-Windows platforms experimental at this time. So maybe something like "Alternatively, PostgreSQL can be built using Meson. This is the only option for building PostgreSQL in Windows using Visual Something[*]. For other platforms, using Meson is currently experimental." [*] What is the correct name for this?
Hi. > "Alternatively, PostgreSQL can be built using Meson. This is the only > option for building PostgreSQL in Windows using Visual Something[*]. > For other platforms, using Meson is currently experimental." +1 good catch > [*] What is the correct name for this? I believe in this section it should be "Visual Studio" as we specify elsewhere [1][2]. In [2] we name specific required versions. Maybe we should reference this section. While on it, in [2] section 17.7.5 is named "Visual". I don't think such a product exists and find it confusing. Maybe we should rename the section to "Visual Studio". Also I don't see any mention of the minimum required version of Ninja. I think we should add it too, or maybe reference the corresponding section I couldn't find in "17.1 Requirements" [1]: https://www.postgresql.org/docs/devel/install-meson.html [2]: https://www.postgresql.org/docs/devel/installation-platform-notes.html -- Best regards, Aleksander Alekseev
Hi, > > [*] What is the correct name for this? > > I believe in this section it should be "Visual Studio" as we specify > elsewhere [1][2]. In [2] we name specific required versions. Maybe we > should reference this section. > > While on it, in [2] section 17.7.5 is named "Visual". I don't think > such a product exists and find it confusing. Maybe we should rename > the section to "Visual Studio". Here are corresponding patches. > Also I don't see any mention of the minimum required version of Ninja. > I think we should add it too, or maybe reference the corresponding > section I couldn't find in "17.1 Requirements" > > [1]: https://www.postgresql.org/docs/devel/install-meson.html > [2]: https://www.postgresql.org/docs/devel/installation-platform-notes.html By a quick look on the buildfarm we seem to use Ninja >= 1.11.1. However since Meson can use both Ninja and VS as a backend I'm not certain which section would be most appropriate for naming the minimal required version of Ninja. -- Best regards, Aleksander Alekseev
Attachment
On Thu, May 30, 2024 at 6:32 AM Aleksander Alekseev <aleksander@timescale.com> wrote:
By a quick look on the buildfarm we seem to use Ninja >= 1.11.1.
However since Meson can use both Ninja and VS as a backend I'm not
certain which section would be most appropriate for naming the minimal
required version of Ninja.
When I tried building with the VS backend it blew up, I don't recall the details. I think we should just use ninja everywhere. That keeps things simple. On Windows I just install python and then do "pip install meson ninja"
cheers
andrew
Hi, >> By a quick look on the buildfarm we seem to use Ninja >= 1.11.1. >> However since Meson can use both Ninja and VS as a backend I'm not >> certain which section would be most appropriate for naming the minimal >> required version of Ninja. > > When I tried building with the VS backend it blew up, I don't recall the details. I think we should just use ninja everywhere.That keeps things simple. On Windows I just install python and then do "pip install meson ninja" If we know that it doesn't work I suggest removing mention of --backend option from [1] until it will, in order to avoid any confusion. [1]: https://www.postgresql.org/docs/devel/install-meson.html -- Best regards, Aleksander Alekseev
Hi, On May 30, 2024 8:03:33 AM PDT, Andrew Dunstan <andrew@dunslane.net> wrote: >On Thu, May 30, 2024 at 6:32 AM Aleksander Alekseev < >aleksander@timescale.com> wrote: > >> >> >> By a quick look on the buildfarm we seem to use Ninja >= 1.11.1. >> However since Meson can use both Ninja and VS as a backend I'm not >> certain which section would be most appropriate for naming the minimal >> required version of Ninja. >> >> >When I tried building with the VS backend it blew up, I don't recall the >details. I think we should just use ninja everywhere. That keeps things >simple. VS should work, and if not, we should fix it. It's slow, so I'd not use it for scheduled builds, but for people developingusing visual studio. Andres -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Hi, > VS should work, and if not, we should fix it. It's slow, so I'd not use it for scheduled builds, but for people developingusing visual studio. Since no one complained, should we assume that there are actually no such people? If this is the case then VS arguably doesn't give any value that would make it worth maintaining. -- Best regards, Aleksander Alekseev
On Wed, May 29, 2024 at 2:41 AM Peter Eisentraut <peter@eisentraut.org> wrote: > "Alternatively, PostgreSQL can be built using Meson. This is the only > option for building PostgreSQL in Windows using Visual Something[*]. > For other platforms, using Meson is currently experimental." Is it, though? I feel like we're beyond the experimental stage now. -- Robert Haas EDB: http://www.enterprisedb.com
On Tue, 4 Jun 2024 at 16:25, Robert Haas <robertmhaas@gmail.com> wrote:
On Wed, May 29, 2024 at 2:41 AM Peter Eisentraut <peter@eisentraut.org> wrote:
> "Alternatively, PostgreSQL can be built using Meson. This is the only
> option for building PostgreSQL in Windows using Visual Something[*].
> For other platforms, using Meson is currently experimental."
Is it, though? I feel like we're beyond the experimental stage now.
I clearly missed the discussion in which it was decided to remove the old MSVC++ support from the tree (and am disappointed about that as I would have objected loudly). Having recently started testing Meson on Windows when I realised that change had been made, and having to update builds for pgAdmin and the Windows installers, I think it's clear it's far more experimental on that platform than it is on Linux at least.
Dave Page
pgAdmin: https://www.pgadmin.org
On 04/06/2024 18:28, Dave Page wrote: > I clearly missed the discussion in which it was decided to remove the > old MSVC++ support from the tree (and am disappointed about that as I > would have objected loudly). Having recently started testing Meson on > Windows when I realised that change had been made, and having to update > builds for pgAdmin and the Windows installers, I think it's clear it's > far more experimental on that platform than it is on Linux at least. What kind of issues did you run into? Have they been fixed since? -- Heikki Linnakangas Neon (https://neon.tech)
On 04.06.24 17:24, Robert Haas wrote: > On Wed, May 29, 2024 at 2:41 AM Peter Eisentraut <peter@eisentraut.org> wrote: >> "Alternatively, PostgreSQL can be built using Meson. This is the only >> option for building PostgreSQL in Windows using Visual Something[*]. >> For other platforms, using Meson is currently experimental." > > Is it, though? I feel like we're beyond the experimental stage now. Experimental is probably too harsh a word now. But it doesn't have feature parity with configure/make yet (for example, no .bc files), so I wouldn't recommend it for production or packaging builds. Then, there are issues like [0]. If it's experimental, then this is like, meh, we'll fix it later. If not, then it's a bug. More generally, I don't think we've really done a comprehensive check of how popular extensions build against pgxs-from-meson. Packagers that make their production builds using meson now might be signing up for a long tail of the unknown. [0]: https://www.postgresql.org/message-id/49e97fd0-c17e-4cbc-aeee-80ac51400736@eisentraut.org
On Tue, Jun 4, 2024 at 12:56 PM Peter Eisentraut <peter@eisentraut.org> wrote: > Experimental is probably too harsh a word now. > > But it doesn't have feature parity with configure/make yet (for example, > no .bc files), so I wouldn't recommend it for production or packaging > builds. That's unfortunate. :-( > Then, there are issues like [0]. If it's experimental, then this is > like, meh, we'll fix it later. If not, then it's a bug. This feels like a case where I'd have to read the entire thread to understand what the issue is. > More generally, I don't think we've really done a comprehensive check of > how popular extensions build against pgxs-from-meson. Packagers that > make their production builds using meson now might be signing up for a > long tail of the unknown. That's a fair point, and I don't know what to do about it, but it seems like something that needs to be addressed. -- Robert Haas EDB: http://www.enterprisedb.com
Hi
On Tue, 4 Jun 2024 at 17:36, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
On 04/06/2024 18:28, Dave Page wrote:
> I clearly missed the discussion in which it was decided to remove the
> old MSVC++ support from the tree (and am disappointed about that as I
> would have objected loudly). Having recently started testing Meson on
> Windows when I realised that change had been made, and having to update
> builds for pgAdmin and the Windows installers, I think it's clear it's
> far more experimental on that platform than it is on Linux at least.
What kind of issues did you run into? Have they been fixed since?
zlib detection (https://www.postgresql.org/message-id/CA+OCxozrPZx57ue8rmhq6CD1Jic5uqKh80=vTpZurSKESn-dkw@mail.gmail.com) for which Nazir worked up an as-yet-uncommitted patch.
uuid detection, which Andrew fixed.
I also ran into an issue in which the build fails if both gssapi and openssl are enabled, but it turns out that's a code issue that affects at least v16 with the old build system as well.
Dave Page
pgAdmin: https://www.pgadmin.org