[issue37839] makesetup Doesn't Handle Defines with Equal Sign

[Jamie Bliss]

Jamie Bliss  added the comment:

Similarly, stumbled across this working on 
https://github.com/pyz-dispenser/cpython-static

This is particularly problematic because of the SQLite module's MODULE_NAME 
macro.

--
nosy: +astronouth7303

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37839] makesetup Doesn't Handle Defines with Equal Sign

[John Muth]

John Muth  added the comment:

I ran into the same issue. This patch fixed it for me.

diff --git a/Modules/makesetup b/Modules/makesetup
index eac97ad134..0fbac03833 100755
--- a/Modules/makesetup
+++ b/Modules/makesetup
@@ -133,6 +133,7 @@ sed -e 's/[ ]*#.*//' -e '/^[]*$/d' |
 
# Output DEFS in reverse order so first definition overrides
case $line in
+   *-D*) ;;
*=*)DEFS="$line$NL$DEFS"; continue;;
'include '*)DEFS="$line$NL$DEFS"; continue;;
'*noobjects*')

--
nosy: +John Muth

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37839] makesetup Doesn't Handle Defines with Equal Sign

[Will Bond]

New submission from Will Bond :

Using 3.8.0b3 on macOS. I'm doing a custom compile with (heavy) modifications 
to Modules/Setup.local. Whenever I add a define rule to a module line that 
includes an equal sign, e.g.:

_sqlite3 -DMODULE_NAME=_sqlite3 _sqlite/module.c _sqlite/cache.c 
_sqlite/connection.c _sqlite/cursor.c _sqlite/microprotocols.c 
_sqlite/prepare_protocol.c _sqlite/row.c _sqlite/statement.c _sqlite/util.c 
-I../env/include -I\$(srcdir)/Modules/_sqlite ../env/lib/libsqlite3.a

makesetup appears to treat this as a Makefile variable definition, which places 
the rule in the wrong part of the Makefile. In my situation, this causes 
_sqlite3 to be compiled as a shared library instead of statically.

I see this was peripherally reported at https://bugs.python.org/issue35184, but 
in that case the =1 was just dropped rather than solving the underlying issue. 
For many situations, dropping the =1 works, but in others it is not.

Not that this is necessarily helpful, but I do know that this used to work with 
Python 3.3.

--
messages: 349543
nosy: wbond
priority: normal
severity: normal
status: open
title: makesetup Doesn't Handle Defines with Equal Sign
type: compile error
versions: Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com