homepage

I have not had test_distutils succeed in ages. It looks like various header files are not being passed to the compiler properly as all three test failures stem from PyModuleDef_HEAD_INIT supposedly not existing or some other macro. Below is an example failure
test_build_ext (distutils.tests.test_build_ext.BuildExtTestCase) ... /var/folders/00/030sr000h01000cxqpysvccm000c37/T/tmpx392aa/xxmodule.c:341:5: error: use of undeclared identifier
 'PyModuleDef_HEAD_INIT'
 PyModuleDef_HEAD_INIT,
 ^
/var/folders/00/030sr000h01000cxqpysvccm000c37/T/tmpx392aa/xxmodule.c:340:27: error: variable has incomplete type
 'struct PyModuleDef'
static struct PyModuleDef xxmodule = {
 ^
/var/folders/00/030sr000h01000cxqpysvccm000c37/T/tmpx392aa/xxmodule.c:340:15: note: forward declaration of
 'struct PyModuleDef'
static struct PyModuleDef xxmodule = {
 ^
/var/folders/00/030sr000h01000cxqpysvccm000c37/T/tmpx392aa/xxmodule.c:370:9: warning: implicit declaration of function
 'PyModule_Create' is invalid in C99 [-Wimplicit-function-declaration]
 m = PyModule_Create(&xxmodule);
 ^
/var/folders/00/030sr000h01000cxqpysvccm000c37/T/tmpx392aa/xxmodule.c:392:5: error: void function 'PyInit_xx' should
 not return a value [-Wreturn-type]
 return m;
 ^ ~
/var/folders/00/030sr000h01000cxqpysvccm000c37/T/tmpx392aa/xxmodule.c:395:5: error: void function 'PyInit_xx' should
 not return a value [-Wreturn-type]
 return NULL;
 ^ ~~~~
1 warning and 4 errors generated.
ERROR

Brett, what configure options are you using and what version of clang? I don't see these errors with the current Apple clang (Xcode 4.6.2): 
$ clang --version
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.4.0
Thread model: posix

Does the compiler use the correct header files? The error messages seem to indicate that the 2.7 headers are used instead of the 3.4 ones (all missing identifiers were introduced in py3k and are not in 2.x)
FWIW, the distutils tests work fine on my machine (OSX 10.8, latest Xcode 4, framework build)

> echo $CPPFLAGS
-I /Users/bcannon/Developer/include -I/Users/bcannon/Developer/Cellar/readline/6.2.4/include
> echo $LDFLAGS
-L /Users/bcannon/Developer/lib -L/Users/bcannon/Developer/Cellar/readline/6.2.4/lib
> echo $CFLAGS
-Wno-unused-value -Wno-empty-body -Qunused-arguments
So ~/Developer/include does have Python installations in there (it's my homebrew include directory) along with sqlite3 and any other packages I have installed to be able to test more. Chances are the headers in homebrew are taking precedence over what's in the build directory during test_distutils run and that's where the conflict is coming in.
If that's true, does this simply mean I need to build Python without any installed libraries to avoid this conflict? Or does this go away if I don't have Homebrew in a non-standard location?

On 7 Jun, 2013, at 16:54, Brett Cannon <report@bugs.python.org> wrote:
> 
> If that's true, does this simply mean I need to build Python without any installed libraries to avoid this conflict?
That's correct. There are other bugreports about other python installations influencing the build, although I'd have to search for the bug number. 
IMHO the root cause for this is that the source/build directories for Python's build are inserted at the wrong location in the compiler search path. Fixing that should be fairly easy, but does require search through the makefile and configure script, which is why I haven't actually tried to fix this yet.
> Or does this go away if I don't have Homebrew in a non-standard location?
Doesn't homebrew use /usr/local as the default location? That would be worse, as there is no easy way to tell the compiler to exclude /usr/local from its default search path.

I'll change the title to make it more obvious what the problem is.
And yes, Homebrew by default uses /usr/local if I remember correctly.

I'm not sure what's going on here, the build already seems to behave correctly.
What I've done:
* Create a python installation in /opt/python2.7
 (configure --prefix=/opt/python2.7; make; make install)
* Now build and the tip of the default branch:
 (./configure --prefix=/tmp/cp34 CPPFLAGS="-I/opt/python2.7/include" LDFLAGS="-L/opt/python2.7/lib" CFLAGS="-Wno-unused-value -Wno-empty-body -Qunused-arguments" CC=clang; make; make test)
Tests passed correctly.
I'm now rerunning the build with '-I/opt/python2.7/include/python2.7' to ensure that the '#include "Python.h"' could find 2.7 header on the compiler search path.

Also the compiler invocations looks fine:
for the main build:
...
clang -c -Wno-unused-result -Werror=declaration-after-statement -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Wno-unused-value -Wno-empty-body -Qunused-arguments -I. -IInclude -I../Include -I/opt/python2.7/include/python2.7 -DPy_BUILD_CORE -o Python/_warnings.o ../Python/_warnings.c
...
And for an extension:
clang -Wno-unused-result -Werror=declaration-after-statement -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Wno-unused-value -Wno-empty-body -Qunused-arguments -DHAVE_EXPAT_CONFIG_H=1 -DUSE_PYEXPAT_CAPI -I/Users/ronald/Projects/python/rw/default/Modules/expat -I../Include -I. -IInclude -I/opt/python2.7/include/python2.7 -I/usr/local/include -I/Users/ronald/Projects/python/rw/default/Include -I/Users/ronald/Projects/python/rw/default/build2 -c /Users/ronald/Projects/python/rw/default/Modules/_elementtree.c -o build/temp.macosx-10.8-x86_64-3.4/Users/ronald/Projects/python/rw/default/Modules/_elementtree.o
(Both should be a single line, not sure of that survives copy&paste)
Both with -I/opt/python2.7/include and -I/opt/python2.7/include/python2.7 the build works correctly, and test_build_ext passes without problems.
I have no idea why this failed on Brett's machine :-(

I'm closing to close this then if Ronald can't reproduce as I have changed computers now and so my setup has shifted. Hopefully I was just a random case.