-
-
Notifications
You must be signed in to change notification settings - Fork 30.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bpo-39026: Allow relative include paths #20181
Conversation
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 |
@@ -6,7 +6,7 @@ | |||
extern "C" { | |||
#endif | |||
|
|||
#include "cpython/initconfig.h" |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
gcc main.c
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO it's not the right approach: https://bugs.python.org/issue39026#msg369242
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 |
Prior to this change, the following would fail to compile with gcc main.c
The compiler would complain that cpython/initconfig.h didn't exist.
https://bugs.python.org/issue39026