bpo-39026: Allow relative include paths by knjmooney · Pull Request #20181 · python/cpython

the-knights-who-say-ni

Prior to this change, the following would fail to compile with gcc main.c

#include "include/python3.9/Python.h"
int main() {}

The compiler would complain that cpython/initconfig.h didn't exist.

https://bugs.python.org/issue39026

Prior to this change, the following would fail to compile with gcc main.c

    #include "include/python3.9/Python.h"
    int main() {}

The compiler would complain that cpython/initconfig.h didn't exist.

This was broken in python 3.8

		extern "C" {
		#endif

		#include "cpython/initconfig.h"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cpython/ subdirectory should not be in the list of include directory.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, but there's no need to put cpython in the list of include directories. pystate.h and inticonfig.h are in the same directory which is the first path searched by the preprocessor. At least this is true according to Wikipedia, GNU docs and visual studio docs. Prior to this change, you needed to update the default include path to compile the following app.

#include "include/python3.9/Python.h"
int main() {}

This now compiles without having to update the default include paths.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was especially useful prior to python 3.8, you could have multiple files that look like

#include "deps/python3.7/Python.h"
get_python_37_data();

and

#include "deps/python3.6/Python.h"
get_python_36_data();

and at runtime determine which version of get_python_xx_data() to use. These would both compile without specialising your include path for each source file.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This issue has been open for a while, but the current 3.10 build from the python site still hasn't fixed the framework. Is this PR being held on the idea it is better to not integrate and rename the files and references?

Also on top of this Xcode will complain bitterly about python headers using double quoted rather than angle bracket syntax. This is the other thing breaking embedding python on macOS apps.

It could be solved by pragma, by moving to angle brackets or by including instructions to disable that warning

I wrote a different fix: PR #29488. Can someone please check if it fix the issue with Xcode?

Thanks for working on this issue. I fixed the issue differently: #29488