Issue 40642: Cpython "pystate.h" subdirectory wrong

Line 9 of pystate.h is:
#include "cpython/initconfig.h"
should be:
#include "./initconfig.h"
since pystate.h is already inside cpython dir.

Won't either one work, since "Include" is in the "search path"? Is this causing an actual problem? You have this marked as "compile error", but haven't shown any information about the error, such as what compiler, how it's being invoked, and what the error message is. We need some more information.

If this were to be changed (which I'm not advocating unless there's a real problem), would it be better as "initconfig.h" or "./initconfig.h"? I think they're equivalent.

In hindsight I provided absolutely nothing, new to this, bound to make dumb mistakes.

Compiler error:

In file included from /usr/include/python3.8/pystate.h:129,
                 from /usr/include/python3.8/genobject.h:11,
                 from /usr/include/python3.8/Python.h:121,
                 from cpppython.cpp:2:
/usr/include/python3.8/cpython/pystate.h:9:10: fatal error: cpython/initconfig.h: No such file or directory
    9 | #include "cpython/initconfig.h"
      |          ^~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

Compiler version:
gcc version 9.3.0 (Arch Linux 9.3.0-1)

About the change, yeah "initconfig.h" and the other one are the same, if it is a real problem then there is no need for "./"

After changing it to just "initconfig.h" the code compiled normally. From my understanding since initconfig.h is already inside the folder cpython using "cpython/initconfig.h" will try to look for another cpython folder inside the cpython folder and then look for initconfig thus the error.

Thanks for the info.

It's weird that this is just showing up for you, and I assume works everywhere else. How are you invoking the compiler, via make, or something else?

And, what's the gcc command line look like when this specific file fails?

I grepped the source code, and didn't see anywhere else where we import something this way, so maybe that's a reason to change it.

As for the "./" think: maybe using it would be a better hint as to what's going on.

But I'd like to hear from other core devs and get their opinion on any change, first.

The problem occurs if you:

   #include <python3.8/Python.h>

on *nix systems.  Note `/usr/include/` is in the system include path.  One workaround is to `-I/usr/include/python3.8` and then `#include <Python.h>`.  Another workaround is to comment out:

   // #include "cpython/initconfig.h"

in `cpython/pystate.h`.

A fix would be appreciated, so that `#include <python3.8/Python.h>` would work out of the box (without having to add `-I`).

Related: https://stackoverflow.com/q/63211981/1131467

After studying the include directives in the Include folder, I think the best fix would be:

In Include/cpython/state.h:

    - #include "cpython/initconfig.h"
    + #include "initconfig.h"

this will mean that state.h will find initconfig.h using a file-relative include (as all the other include directives do), instead of relying on the installed Include directory being put in the header search path.

As this include directive is the only one with this property, the benefit of this change would be that the Include folder would be able to be installed in any subdirectory of a search path, rather than requiring its own dedicated one.

This would mean (for example) you could install different versions of the Python headers side by side and then select between them using preprocessor directives - rather than having to switch up global compiler options.

Dup of #39026.  And the proposed fix is nack'ed in #39026.

Having two header files with the same name in two directories which are part of the include directories is causing issues like this one :-(

For the internal C API, I solve the issue by adding "pycore_" prefix to filenames.

Maybe pystate.h should be renamed to cpython_pystate.h to avoid to fix the issue. It would include cpython_initconfig.h.

I mark this issue as a duplicate of bpo-39026.

resolution: duplicate
stage: patch review -> resolved

pull_requests: + pull_request23514
stage: patch review