This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: pyconfig.h #defines macros in global namespace
Type: Stage: resolved
Components: Installation Versions: Python 3.4, Python 2.7
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: doko, fsateler, lemburg
Priority: normal Keywords:

Created on 2014-02-25 14:03 by fsateler, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (4)
msg212178 - (view) Author: Felipe Sateler (fsateler) Date: 2014-02-25 14:03
I reported the following in the debian bug tracker[1], and it was requested that I report it here.

pyconfig.h has definitions like the following:

    #define HAVE_DIRENT_H 1
    #define HAVE_DLFCN_H 1

These are the general form feature test macros take in practically any
software project. This means that when building a python module these
feature macros conflict. In the best scenario, you get a redefinition
warning. In the worst scenario, the build breaks because of inconsistent
#defines between the module and pyconfig.h.

Please either don't include pycongfig.h from Python.h, or appropiately
namespace the test macros (PYTHON_HAVE_* or something like that).


[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738726
msg212180 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2014-02-25 14:19
no, I requested that you propose a patch.  And the question why you need to include Python.h everywhere where it could do harm is unanswered too.
msg212181 - (view) Author: Felipe Sateler (fsateler) Date: 2014-02-25 14:29
I'm sorry but I definitely don't have time or knowledge about python
to propose a patch (simply removing pyconfig.h clearly doesn't work).

As to the question, please clarify. I have a python module, which
includes Python.h, which includes pyconfig.h. I don't include Python.h
everywhere. My build system does use several HAVE_* macros. It seems
as if no breakage has occurred, but this is not guaranteed. And I
shouldn't need to tiptoe around other libraries feature test macros,
especially when they infringe on the global namespace.

-- 

Saludos,
Felipe Sateler
msg212183 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2014-02-25 15:20
On 25.02.2014 15:29, Felipe Sateler wrote:
> 
> I'm sorry but I definitely don't have time or knowledge about python
> to propose a patch (simply removing pyconfig.h clearly doesn't work).
> 
> As to the question, please clarify. I have a python module, which
> includes Python.h, which includes pyconfig.h. I don't include Python.h
> everywhere. My build system does use several HAVE_* macros. It seems
> as if no breakage has occurred, but this is not guaranteed. And I
> shouldn't need to tiptoe around other libraries feature test macros,
> especially when they infringe on the global namespace.

Those HAVE_* macros are mostly standard autoconf macros, which you'll
find in lots of libraries, not just Python.

You can use them in your Python module as well, and of course,
add more autoconf macros as needed using a separate .h file.

C doesn't have namespaces like C++ does, so the only possible change
would be to prefix all of those macros with "PY_". Since this is the
first time I've ever heard anyone complain about those macros,
I doubt that this is a general problem. People are usually happy
with building on the autoconf tests we already have in Python.
History
Date User Action Args
2022-04-11 14:57:59adminsetgithub: 64967
2021-10-20 10:59:50iritkatrielsetstatus: open -> closed
resolution: rejected
stage: resolved
2014-02-25 15:20:40lemburgsetnosy: + lemburg
messages: + msg212183
2014-02-25 14:29:42fsatelersetmessages: + msg212181
2014-02-25 14:19:11dokosetnosy: + doko
messages: + msg212180
2014-02-25 14:03:30fsatelercreate