On default, have this single failure on my box (Gentoo amd64):

======================================================================
FAIL: test_sysconfig_module (distutils.tests.test_sysconfig.SysconfigTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/gbr/devel/python/Lib/distutils/tests/test_sysconfig.py", line 105, in test_sysconfig_module
    self.assertEqual(global_sysconfig.get_config_var('LDSHARED'),sysconfig.get_config_var('LDSHARED'))
AssertionError: 'gcc -pthread -shared' != '/usr/bin/clang -shared'
- gcc -pthread -shared
+ /usr/bin/clang -shared


While clang is installed, I haven't set anything to clang while configuring, or in my environment.

This test failure points at a few issues:

 - The CFLAGS modification should only be taking place on OS X systems.  AFAICT, all of that code is protected by sys.platform checks.  One possible culprit, though, might be distutils test test_unixccompiler which attempts to test various platforms by mocking sys.platform.  It so happens that "darwin" is the first platform it tests and, while the test setup and teardown does preserve and restore the get_config_var function in distutils.sysconfig, it doesn't preserve the module global _config_vars which distutils.sysconfig uses to cache the results of parsing the Makefile.  I wonder what happens if test_unixccompiler happens to be the first caller of distutils.sys_config_vars().  I think it will get invoked with sys.platform = 'darwin' and trigger the customization code on what becomes the cached copy for remaining tests.  I'm attaching a patch to preserve and restore the cached values as well.  Georg, I'd appreciate it if you could try this on your system.

 - More importantly, the test failure shows that the code we added for Xcode 4 support in Issue13590 only addressed distutils.sysconfig and not the identical code in standalone sysconfig.  With the removal of packaging in 3.3, AFAIK there now is nothing in the standard library that should depend on this at the moment but it will undoubtedly be an issue for distutil2 and future packaging features.  We had discussed dealing with this by factoring out the common customization code into a separate module to avoid DRY but I didn't get that done.  I'm attaching a first rough patch that does that; it is only very lightly tested and so should not be a candidate for 3.3.0b1.

I recommend the following steps:
  1. For 3.3.0b1, either ignore the test failure or add a skip for 3.3.0b1.  (This failure will also likely show up if OS X installer users attempt to run the tests.)
  2. Resolve the test failure on non-OS X platforms.
  3. Test and review the refactoring patch and plan to push it for 3.3.0rc1.
  4. Post 3.3.0, regardless of the outcome of the proposed packaging PEPs, finally replace distutils.sysconfig with sysconfig.  Attempting to continue to maintain both of them is just asking for more trouble.

Sounds good.

Moving stuff common to both sysconfig modules into a shared module sounds good, but the existence and API of distutils.sysconfig needs to be preserved.

Moving to blocker for beta2.

Georg, are you still able to reproduce this? I've subsequently tried on a Debian platform with an installed clang and could not reproduce.  And, after further inspecting the current code, I really don't see how the clang substitution could happen on a non-darwin platform.  My initial speculation about test_unixcompiler was incorrect as well as the proposed patch to preserve config vars in it (that test does not actually affect _config_vars and _config_vars is a dict so has to be deep-copied to be restorable).  I'm proceeding with the _osx_support consolidation but I sure would like to know what was behind the behavior you reported.

I suspect the problem is related to http://bugs.python.org/issue15298.

Basically the global sysconfig module caches the results of parsing Makefile in Lib/_sysconfigdata.py.  This can cause you to get the config vars from an old configure and build.

I don't see how this is related to Issue15298.  In the failure here, sysconfig returns the expected value; the problem is with what distutils.sysconfig returns.

New changeset d76b83803e7e by Ned Deily in branch 'default':
Issue #15184: Ensure consistent results of OS X configuration
http://hg.python.org/cpython/rev/d76b83803e7e

I've committed an updated version of the refactoring patch which attempts to handle some additional edge cases and which includes a number of additional tests.  I still have not been able to reproduce the original failure so I'm setting the status to pending awaiting a test report from Georg or someone else who is able to reproduce it.

Buildbot test failure:
http://buildbot.python.org/all/builders/AMD64%20Snow%20Leopard%203.x/builds/66

Damn, I don't have clang on this machine.  Will install and test.

> Buildbot test failure:
> http://buildbot.python.org/all/builders/AMD64%20Snow%20Leopard%203.x/builds/66

These failures are not new, and the buildbot is an unstable one.

As for clang, the Lion buildbot uses it and is green. Its configure line is "./configure --with-pydebug CC=clang":
http://buildbot.python.org/all/builders/AMD64%20Lion%203.x

The problem isn't with clang. The problem was that the test appeared to be taking an OS X only code path apparently because a clang was installed on a Gentoo machine.

OK, test passes here now with clang installed.

FYI, Added two FreeBSD based buildslaves to the cluster not long ago, one is dedicated to python+CLANG
 
http://buildbot.python.org/all/buildslaves/koobs-freebsd-clang

The new buildbot failure is due to that buildbot using env variables for some of the config variables during execution.  The new tests need to isolate themselves from that.  Should have a fix shortly.

New changeset 295b715b6875 by Ned Deily in branch 'default':
Issue #15184: Ensure configuration-related environment variables
http://hg.python.org/cpython/rev/295b715b6875

I believe I've fixed the buildbot failure but the buildbot is not very stable and test runs aren't always completing.  I'll check back on it later.

New changeset 31349bc40214 by Ned Deily in branch 'default':
Issue #15184: Fix test__remove_unsupported_archs failures on 10.6
http://hg.python.org/cpython/rev/31349bc40214

New changeset c286d50ecd19 by Ned Deily in branch 'default':
Issue #15184: Some config variables in test_sysconfig_module
http://hg.python.org/cpython/rev/c286d50ecd19

The buildbot failures were reproducible on OS X 10.6 with Xcode 3. With the latest two fixes and with the fixes for Issue15188, I believe this issue is resolved for 3.3.