meson: Stop using deprecated way getting path of files
Hi,
The just released meson 1.3 strongly deprecated a hack we were using, emitting
a noisy warning (the hack basically depended on an implementation detail to
work). Turns out there has been a better way available for a while, I just
hadn't found it. 1.4 added a more convenient approach, but we can't rely on
that.
Everything continues to work, but the warning is annoying.
The warning:
Message: checking for file conflicts between source and build directory
../home/andres/src/postgresql/meson.build:2972: DEPRECATION: Project uses feature that was always broken, and is now deprecated since '1.3.0': str.format: Value other than strings, integers, bools, options, dictionaries and lists thereof..
[...]
WARNING: Broken features used:
* 1.3.0: {'str.format: Value other than strings, integers, bools, options, dictionaries and lists thereof.'}
I plan to apply this soon, unless I hear some opposition / better ideas / ....
Greetings,
Andres Freund
Attachments:
v1-0001-meson-Stop-using-deprecated-way-getting-path-of-f.patchtext/x-diff; charset=us-asciiDownload
From d296c088ceadeac281a54d6f7f748112c5efb33a Mon Sep 17 00:00:00 2001
From: Andres Freund <andres@anarazel.de>
Date: Wed, 29 Nov 2023 10:47:20 -0800
Subject: [PATCH v1] meson: Stop using deprecated way getting path of files
The just released meson 1.3 strongly deprecated a hack we were using, emitting
a noisy warning (the hack basically depended on an implementation detail to
work). Turns out there has been a better way available for a while, I just
hadn't found it. 1.4 added a more convenient approach, but we can't rely on
that.
Author:
Reviewed-by:
Discussion: https://postgr.es/m/
Backpatch: 16-, where the meson build was added.
---
meson.build | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/meson.build b/meson.build
index 0095fb183af..d8ff5cb51f0 100644
--- a/meson.build
+++ b/meson.build
@@ -2924,8 +2924,12 @@ potentially_conflicting_files = []
foreach t : potentially_conflicting_files_t
potentially_conflicting_files += t.full_path()
endforeach
-foreach t : configure_files
- t = '@0@'.format(t)
+foreach t1 : configure_files
+ if meson.version().version_compare('>=0.59')
+ t = fs.parent(t1) / fs.name(t1)
+ else
+ t = '@0@'.format(t1)
+ endif
potentially_conflicting_files += meson.current_build_dir() / t
endforeach
foreach sub, fnames : generated_sources_ac
--
2.38.0
This looks good to me. What is our limiting factor on bumping the
minimum Meson version?
While we are on the topic of Meson, it would be great if you could take
a look at this thread[0]/messages/by-id/CWTM35CAUKRT.1733OSMXUZW7@neon.tech, where I am trying to compile Postgres with
-fsanitize=address,undefined (-Db_sanitize=address,undefined).
[0]: /messages/by-id/CWTM35CAUKRT.1733OSMXUZW7@neon.tech
--
Tristan Partin
Neon (https://neon.tech)
Hi,
On 2023-11-29 13:11:23 -0600, Tristan Partin wrote:
This looks good to me.
Cool.
What is our limiting factor on bumping the minimum Meson version?
Old distro versions, particularly ones where the distro just has an older
python. It's one thing to require installing meson but quite another to also
require building python. There's some other ongoing discussion about
establishing the minimum baseline in a somewhat more, uh, formalized way:
/messages/by-id/CA+hUKGLhNs5geZaVNj2EJ79Dx9W8fyWUU3HxcpZy55sMGcY=iA@mail.gmail.com
While we are on the topic of Meson, it would be great if you could take a
look at this thread[0], where I am trying to compile Postgres with
-fsanitize=address,undefined (-Db_sanitize=address,undefined).
Done. Not sure it helps you much though :)
Greetings,
Andres Freund
On Wed Nov 29, 2023 at 1:42 PM CST, Andres Freund wrote:
Hi,
On 2023-11-29 13:11:23 -0600, Tristan Partin wrote:
What is our limiting factor on bumping the minimum Meson version?
Old distro versions, particularly ones where the distro just has an older
python. It's one thing to require installing meson but quite another to also
require building python. There's some other ongoing discussion about
establishing the minimum baseline in a somewhat more, uh, formalized way:
/messages/by-id/CA+hUKGLhNs5geZaVNj2EJ79Dx9W8fyWUU3HxcpZy55sMGcY=iA@mail.gmail.com
I'll take a look there. According to Meson, the following versions had
Python version bumps:
0.61.5: 3.6
0.56.2: 3.5
0.45.1: 3.4
Taking a look at pkgs.org, Debian 10, Ubuntu 20.04, and Oracle Linux
7 (a RHEL re-spin), and CentOS 7, all have >= Python 3.6.8. Granted,
this isn't the whole picture of what Postgres supports from version 16+.
To put things in perspective, Python 3.6 was released on December 23,
2016, which is coming up on 7 years. Python 3.6 reached end of life on
the same date in 2021.
Is there a complete list somewhere that talks about what platforms each
version of Postgres supports?
--
Tristan Partin
Neon (https://neon.tech)
On 2023-11-30 Th 16:00, Tristan Partin wrote:
On Wed Nov 29, 2023 at 1:42 PM CST, Andres Freund wrote:
Hi,
On 2023-11-29 13:11:23 -0600, Tristan Partin wrote:
What is our limiting factor on bumping the minimum Meson version?
Old distro versions, particularly ones where the distro just has an
older
python. It's one thing to require installing meson but quite another
to also
require building python. There's some other ongoing discussion about
establishing the minimum baseline in a somewhat more, uh, formalized
way:
/messages/by-id/CA+hUKGLhNs5geZaVNj2EJ79Dx9W8fyWUU3HxcpZy55sMGcY=iA@mail.gmail.comI'll take a look there. According to Meson, the following versions had
Python version bumps:0.61.5: 3.6
0.56.2: 3.5
0.45.1: 3.4Taking a look at pkgs.org, Debian 10, Ubuntu 20.04, and Oracle Linux 7
(a RHEL re-spin), and CentOS 7, all have >= Python 3.6.8. Granted,
this isn't the whole picture of what Postgres supports from version
16+. To put things in perspective, Python 3.6 was released on December
23, 2016, which is coming up on 7 years. Python 3.6 reached end of
life on the same date in 2021.Is there a complete list somewhere that talks about what platforms
each version of Postgres supports?
You can look at animals in the buildfarm. For meson only release 16 and
up matter.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2023-11-29 10:50:53 -0800, Andres Freund wrote:
I plan to apply this soon, unless I hear some opposition / better ideas / ....
Pushed.
On Thu Nov 30, 2023 at 3:46 PM CST, Andrew Dunstan wrote:
On 2023-11-30 Th 16:00, Tristan Partin wrote:
On Wed Nov 29, 2023 at 1:42 PM CST, Andres Freund wrote:
Hi,
On 2023-11-29 13:11:23 -0600, Tristan Partin wrote:
What is our limiting factor on bumping the minimum Meson version?
Old distro versions, particularly ones where the distro just has an
older
python. It's one thing to require installing meson but quite another
to also
require building python. There's some other ongoing discussion about
establishing the minimum baseline in a somewhat more, uh, formalized
way:
/messages/by-id/CA+hUKGLhNs5geZaVNj2EJ79Dx9W8fyWUU3HxcpZy55sMGcY=iA@mail.gmail.comI'll take a look there. According to Meson, the following versions had
Python version bumps:0.61.5: 3.6
0.56.2: 3.5
0.45.1: 3.4Taking a look at pkgs.org, Debian 10, Ubuntu 20.04, and Oracle Linux 7
(a RHEL re-spin), and CentOS 7, all have >= Python 3.6.8. Granted,
this isn't the whole picture of what Postgres supports from version
16+. To put things in perspective, Python 3.6 was released on December
23, 2016, which is coming up on 7 years. Python 3.6 reached end of
life on the same date in 2021.Is there a complete list somewhere that talks about what platforms
each version of Postgres supports?You can look at animals in the buildfarm. For meson only release 16 and
up matter.
On the buildfarm page[0]https://buildfarm.postgresql.org/cgi-bin/show_members.pl, it would be nice if more than just the
compiler versions were stated. It would be nice to have all
build/runtime dependencies listed. For instance, it would be interesting
if there was a json document for each build animal, and perhaps a root
json document which was an amalgomation of the individual documents.
Then I could use a tool like jq to query all the information rather
easily. As-is, I don't know where to search for package versions for
some of the archaic operating systems in the farm. Perhaps other people
have had similar problems in the past. Having a full write-up of every
build machine would also be good for debugging purposes. If I see
openssl tests suddenly failing on one machine, then I can just check the
openssl version, and try to reproduce locally.
I know the buildfarm seems to be a volunteer thing, so asking more of
them seems like a hard ask. Just wanted to throw my thoughts into the
void.
[0]: https://buildfarm.postgresql.org/cgi-bin/show_members.pl
--
Tristan Partin
Neon (https://neon.tech)
"Tristan Partin" <tristan@neon.tech> writes:
On the buildfarm page[0], it would be nice if more than just the
compiler versions were stated. It would be nice to have all
build/runtime dependencies listed.
By and large, we've attempted to address such concerns by extending
the configure script to emit info about versions of things it finds.
So you should look into the configure step's log to see what version
of bison, openssl, etc is in use.
I know the buildfarm seems to be a volunteer thing, so asking more of
them seems like a hard ask.
We certainly aren't going to ask owners to maintain such information
manually. Even if they tried, it'd soon be impossibly out-of-date.
The logging method has the additional advantage that it's accurate
for historical runs as well as whatever the machine has installed
today.
regards, tom lane
On Fri Dec 1, 2023 at 12:07 PM CST, Tom Lane wrote:
"Tristan Partin" <tristan@neon.tech> writes:
On the buildfarm page[0], it would be nice if more than just the
compiler versions were stated. It would be nice to have all
build/runtime dependencies listed.By and large, we've attempted to address such concerns by extending
the configure script to emit info about versions of things it finds.
So you should look into the configure step's log to see what version
of bison, openssl, etc is in use.
Good point. For some reason that slipped my mind. Off into the weeds
I go...
--
Tristan Partin
Neon (https://neon.tech)
On Fri Dec 1, 2023 at 12:16 PM CST, Tristan Partin wrote:
On Fri Dec 1, 2023 at 12:07 PM CST, Tom Lane wrote:
"Tristan Partin" <tristan@neon.tech> writes:
On the buildfarm page[0], it would be nice if more than just the
compiler versions were stated. It would be nice to have all
build/runtime dependencies listed.By and large, we've attempted to address such concerns by extending
the configure script to emit info about versions of things it finds.
So you should look into the configure step's log to see what version
of bison, openssl, etc is in use.Good point. For some reason that slipped my mind. Off into the weeds
I go...
Ok, so what I found is that we still have build farm animals using
Python 3.4, specifically the AIX machines. There was also at least one
Python 3.5 user too. Note that this was a manual check.
I think I'll probably work on a tool for querying information out of the
build farm tonight to make tasks like this much more automated.
--
Tristan Partin
Neon (https://neon.tech)
"Tristan Partin" <tristan@neon.tech> writes:
On Fri Dec 1, 2023 at 12:16 PM CST, Tristan Partin wrote:
Ok, so what I found is that we still have build farm animals using
Python 3.4, specifically the AIX machines. There was also at least one
Python 3.5 user too. Note that this was a manual check.
I think I'll probably work on a tool for querying information out of the
build farm tonight to make tasks like this much more automated.
Not sure what you were using, but are you aware that SQL access to the
buildfarm database is available to project members? My own stock
approach to checking on this sort of thing is like
select * from
(select sysname, snapshot, unnest(string_to_array(log_text, E'\n')) as l
from build_status_log join snapshots using (sysname, snapshot)
where log_stage = 'configure.log') ss
where l like 'checking for builtin %'
regards, tom lane
On Mon Dec 4, 2023 at 2:10 PM CST, Tom Lane wrote:
"Tristan Partin" <tristan@neon.tech> writes:
On Fri Dec 1, 2023 at 12:16 PM CST, Tristan Partin wrote:
Ok, so what I found is that we still have build farm animals using
Python 3.4, specifically the AIX machines. There was also at least one
Python 3.5 user too. Note that this was a manual check.I think I'll probably work on a tool for querying information out of the
build farm tonight to make tasks like this much more automated.Not sure what you were using, but are you aware that SQL access to the
buildfarm database is available to project members? My own stock
approach to checking on this sort of thing is likeselect * from
(select sysname, snapshot, unnest(string_to_array(log_text, E'\n')) as l
from build_status_log join snapshots using (sysname, snapshot)
where log_stage = 'configure.log') ss
where l like 'checking for builtin %'
This looks useful. I had no idea about this. Can you send me any
resources for setting this up? My idea was just to do some web scraping.
--
Tristan Partin
Neon (https://neon.tech)
On Tue, Dec 5, 2023 at 3:27 AM Tristan Partin <tristan@neon.tech> wrote:
On Mon Dec 4, 2023 at 2:10 PM CST, Tom Lane wrote:
Not sure what you were using, but are you aware that SQL access to the
buildfarm database is available to project members? My own stock
approach to checking on this sort of thing is likeselect * from
(select sysname, snapshot, unnest(string_to_array(log_text, E'\n')) as l
from build_status_log join snapshots using (sysname, snapshot)
where log_stage = 'configure.log') ss
where l like 'checking for builtin %'This looks useful. I had no idea about this. Can you send me any
resources for setting this up? My idea was just to do some web scraping.
+1 -- I was vaguely aware of this, but can't find any mention of
specifics in the buildfarm how-to, or other places I thought to look.
On Mon Dec 18, 2023 at 12:43 AM CST, John Naylor wrote:
On Tue, Dec 5, 2023 at 3:27 AM Tristan Partin <tristan@neon.tech> wrote:
On Mon Dec 4, 2023 at 2:10 PM CST, Tom Lane wrote:
Not sure what you were using, but are you aware that SQL access to the
buildfarm database is available to project members? My own stock
approach to checking on this sort of thing is likeselect * from
(select sysname, snapshot, unnest(string_to_array(log_text, E'\n')) as l
from build_status_log join snapshots using (sysname, snapshot)
where log_stage = 'configure.log') ss
where l like 'checking for builtin %'This looks useful. I had no idea about this. Can you send me any
resources for setting this up? My idea was just to do some web scraping.+1 -- I was vaguely aware of this, but can't find any mention of
specifics in the buildfarm how-to, or other places I thought to look.
From my off-list conversations with Andrew, database access to the
buildfarm is for trusted contributors. I do not meet current criteria.
I've thought about building a web-scraper to get at some of this
information for non-trusted contributors. If that interests you, let me
know, and maybe I can build it out over the holiday. Or maybe you meet
the criteria! :)
--
Tristan Partin
Neon (https://neon.tech)