Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom Tromey <tom@tromey.com>
To: Matthieu Longo <matthieu.longo@arm.com>
Cc: <gdb-patches@sourceware.org>,  Tom Tromey <tom@tromey.com>
Subject: Re: [PATCH v3 2/7] gdb: fail configure if Python version is too old for limited API
Date: Tue, 24 Mar 2026 12:53:55 -0600	[thread overview]
Message-ID: <87h5q55a9o.fsf@tromey.com> (raw)
In-Reply-To: <20260309175624.236491-3-matthieu.longo@arm.com> (Matthieu Longo's message of "Mon, 9 Mar 2026 17:56:19 +0000")

>>>>> Matthieu Longo <matthieu.longo@arm.com> writes:

> GDB can be built against the Python limited API using the configure
> flag '--enable-py-limited-api=yes'. This flag is currently experimental,
> and the build is not yet fully successful. Today, the minimum required
> Python version for this option is 3.11. This requirement is not final
> and will be raised to a later version as the migration progresses.

> However, the configure script does not currently report an error if an
> older version of Python is used. Instead, the build fails later with
> numerous errors that are difficult to relate to Python limited API
> compatiblity.

> This patch adds a version check when '--enable-py-limited-api=yes' is
> specified, ensuring that the provided Python version meets the minimum
> requirements for the limited API support. If it does not, configure will
> now fail with a clear error message.

Sorry about the delay on this.

I'm a bit worried about adding a bunch of new python-related configury.
Like are we sure it will agree with what's already in there?  As in,
picking up the same version from the same place, etc?  For instance does
this new code respect --with-python-libdir?

I wonder if instead there could just be a new compile test that is run
when --enable-py-limited-api is used.  This test could just check
PY_VERSION_HEX and #error on failure.

Wouldn't that have the same effect but without adding a ton of new code?

TBH I'd even be happy with not doing this check in configure at all and
saying that if you specify --enable-py-limited-api then you should know
what you're doing and if you mess up you'll just get compile-time
errors.  That is, stick the check in python-internal.h.

Tom

  reply	other threads:[~2026-03-24 18:54 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-09 17:56 [PATCH v3 0/7] gdb: more fixes for Python limited C API support Matthieu Longo
2026-03-09 17:56 ` [PATCH v3 1/7] gdb: introduce rgb_color type to simplify existing code Matthieu Longo
2026-03-09 19:22   ` Tom Tromey
2026-03-11 15:03     ` Simon Marchi
2026-03-11 17:55       ` Matthieu Longo
2026-03-11 18:04         ` Simon Marchi
2026-03-11 18:16         ` Tom Tromey
2026-03-09 17:56 ` [PATCH v3 2/7] gdb: fail configure if Python version is too old for limited API Matthieu Longo
2026-03-24 18:53   ` Tom Tromey [this message]
2026-03-31 10:16     ` Matthieu Longo
2026-04-07 13:36       ` Matthieu Longo
2026-04-07 20:39       ` Tom Tromey
2026-03-09 17:56 ` [PATCH v3 3/7] gdb: add new helpers for retrieving a type's fully qualified name Matthieu Longo
2026-03-24 18:44   ` Tom Tromey
2026-03-09 17:56 ` [PATCH v3 4/7] gdb/python: allow ref_ptr<T, Policy>::new_reference to accept subclasses of T Matthieu Longo
2026-03-09 19:40   ` Tom Tromey
2026-03-10 12:26     ` Matthieu Longo
2026-03-09 17:56 ` [PATCH v3 5/7] gdb/python: flatten functions calling PyObject_New and use gdbpy_ref Matthieu Longo
2026-03-09 20:07   ` Tom Tromey
2026-03-09 17:56 ` [PATCH v3 6/7] gdb/python: add gdbpy_dict_wrapper:allocate_dict helper Matthieu Longo
2026-03-09 20:09   ` Tom Tromey
2026-03-10 12:26     ` Matthieu Longo
2026-03-09 17:56 ` [PATCH v3 7/7] gdb/python: add accessor helpers for __dict__ in Python extension objects Matthieu Longo
2026-03-13 18:09   ` Tom Tromey
2026-03-23 10:28 ` [PATCH v3 0/7] gdb: more fixes for Python limited C API support Matthieu Longo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87h5q55a9o.fsf@tromey.com \
    --to=tom@tromey.com \
    --cc=gdb-patches@sourceware.org \
    --cc=matthieu.longo@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox