[MacPorts] #68265: py311-gnureadline @8.1.2: build failure

[MacPorts]

#68265: py311-gnureadline @8.1.2: build failure
-----------------------------+--------------------------
  Reporter:  MaddTheSane     |      Owner:  stromnov
      Type:  defect          |     Status:  assigned
  Priority:  Normal          |  Milestone:
 Component:  ports           |    Version:  2.8.1
Resolution:                  |   Keywords:  sonama arm64
      Port:  py-gnureadline  |
-----------------------------+--------------------------

Comment (by markmentovai):

 Replying to [comment:1 jmroot]:
 > Looks like [https://github.com/python/cpython/issues/109191], which is
 unexpected because that implies this is building against libedit headers
 instead of its own GNU readline headers.

 gnureadline’s Modules/3.x/readline.c has this:

 {{{
 #ifdef WITH_EDITLINE
 #  include <editline/readline.h>
 #else
 /* GNU readline definitions */
 #  undef HAVE_CONFIG_H /* Else readline/chardefs.h includes strings.h */
 #  include <readline/readline.h>
 #  include <readline/history.h>
 #endif
 }}}

 The problem is that earlier in the same file, there’s

 {{{
 #include "Python.h"
 }}}


 `"Python.h"` is resolved as
 `${prefix}/Library/Frameworks/Python.framework/Versions/3.11/include/python3.11/Python.h`;
 it #includes `"pyconfig.h"` from the same directory, and that file
 contains:

 {{{
 /* Define to build the readline module against Editline. */
 #define WITH_EDITLINE 1
 }}}

 This, of course, refers to Python’s own built-in `readline` module, and
 should not be effective during the build of py-gnureadline, which is
 expecting and has configured itself to use its own embedded copy of GNU
 readline.

 As a fix, I think we can just remove (or replace with `#if 0`) that
 `WITH_EDITLINE` branch.

-- 
Ticket URL: <https://trac.macports.org/ticket/68265#comment:5>
MacPorts <https://www.macports.org/>
Ports system for macOS