bpo-26317: Support OBJC and OBJCXX configure command line variables #20176
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
command line options so that the MacOSX builds can use the clang compiler for the MacOSX-specific Objective C source files. This allows the GNU compiler to be used to build the rest of the project since some of the Objective C system header files are not compilable with the GNU compiler.
…e can force the use of the OBJC compiler when the CC compiler is different. For example, it allows _scproxy.c to be compiled using the clang compiler while the rest of the project uses the GNU C compiler.
ned-deily
added a commit
to ned-deily/cpython
that referenced
this pull request
May 18, 2020
…iables (pythonGH-20176)" This reverts commit 0da5466. The commit is causing make failures on a FreeBSD buildbot. Due to the imminent 3.9.0b1 cutoff, revert this commit for now pending further investigation.
ned-deily
added a commit
that referenced
this pull request
May 18, 2020
arturoescaip
pushed a commit
to arturoescaip/cpython
that referenced
this pull request
May 24, 2020
…ythonGH-20176) Add support to the configure script for OBJC and OBJCXX command line options so that the macOS builds can use the clang compiler for the macOS-specific Objective C source files. This allows third-party compilers, like GNU gcc, to be used to build the rest of the project since some of the Objective C system header files are not compilable by GNU gcc. Co-authored-by: Jeffrey Kintscher <websurfer@surf2c.net> Co-authored-by: Terry Jan Reedy <tjreedy@udel.edu>
arturoescaip
pushed a commit
to arturoescaip/cpython
that referenced
this pull request
May 24, 2020
…iables (pythonGH-20176)" (pythonGH-20182) This reverts commit 0da5466. The commit is causing make failures on a FreeBSD buildbot. Due to the imminent 3.9.0b1 cutoff, revert this commit for now pending further investigation.
|
@ned-deily @websurfer5 I am unsure about the state of this fix since it seems to have been reverted due to a regression on FreeBSD? Do GCC builds on macOS now work with the objective C sources (includes) for the upcoming 3.9 release? |
ax3l
reviewed
Aug 25, 2020
| @@ -1,5 +1,7 @@ | |||
| CC=@CC@ | |||
| LD=@CC@ | |||
| OBJC=@OBJC@ | |||
| OBJCFLAFS=@OBJCFLAGS@ | |||
There was a problem hiding this comment.
Typo according to https://bugs.python.org/issue26317#msg369325
OBJCFLAGS=@OBJCFLAGS@
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add support to the configure script for OBJC and OBJCXX command line options so that the macOS builds can use the clang compiler for the macOS-specific Objective C source files. This allows third-party compilers, like GNU gcc, to be used to build the rest of the project since some of the Objective C system header files are not compilable by GNU gcc.
Also, _scproxy.o is built outside of setup.py so that we can force the use of the OBJC compiler when the CC compiler is different. The Makefile builds _scproxy.o and the setup.py script takes care of using the object file to create the _scproxy module instead of compiling the file itself. This approach is taken because setup.py is designed to use a single compiler for everything. Adding support for a second alternative compiler would require re-plumbing distutils, which is complicated and unnecessary because setup.py allows module definitions to specify object files without any .c source files.
This fixes the PythonLauncher build when CC is set to the GNU C compiler. In this case, OBJC can be set explicitly to "clang", or it can be left out and the configure script will automatically discover the clang compiler as the Objective C compiler. For example, a system that used brew to install the GNU C compiler as gcc-8 can specify CC=gcc-8 and the configure script will discover and use the clang compiler as if OBJC=gcc had been specified on the command line. The same behavior applies to the OBJCXX and CXX options.
Patch contributed by Jeffrey Kintscher (@websurfer5).
https://bugs.python.org/issue26317