[issue20768] pyconfig.h #defines macros in global namespace

[Irit Katriel]

Change by Irit Katriel :


--
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue20768] pyconfig.h #defines macros in global namespace

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

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.

--
nosy: +lemburg

___
Python tracker 

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

[issue20768] pyconfig.h #defines macros in global namespace

[Felipe Sateler]

Felipe Sateler added the comment:

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

--

___
Python tracker 

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

[issue20768] pyconfig.h #defines macros in global namespace

[Matthias Klose]

Matthias Klose added the comment:

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.

--
nosy: +doko

___
Python tracker 

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

[issue20768] pyconfig.h #defines macros in global namespace

[Felipe Sateler]

New submission from Felipe Sateler:

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

--
components: Installation
messages: 212178
nosy: fsateler
priority: normal
severity: normal
status: open
title: pyconfig.h #defines macros in global namespace
versions: Python 2.7, Python 3.4

___
Python tracker 

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