The flags that you need to compile against libpythonXX.lib are hidden inside of the distutils.msvccompiler class.  This is ok if you want to use distutils to compile extensions against the binary, but other build systems need to run initialize() to get access to the compiler_options attribute.  This call requires a bunch of things to be correct (think MSVC on the path, expected names, etc), and fails in a great quantity of vanilla Windows/Python configurations.   

One example includes the scraping function waf:
https://code.google.com/p/waf/source/browse/waflib/Tools/python.py#347

I am also sure SCons does this somewhere (or at least ought to).  

I think these values hard coded into the function ought to be exposed elsewhere to streamline other build systems finding them and linking against the core library.  I was thinking something like adding a function that looked something like get_flags(arch, debugTF), which then the initialize() function draws on.  

I am willing to write a patch, but I wanted to make sure there some consensus about the best way to do this before trooping off.  Thanks

It may be a good idea to make this information directly available in the sysconfig module, for example.  Before working on a patch right away, I’d recommend getting in touch with build tools developers and ask them what other hidden information they are extracting from distutils internals, so that a clean, comprehensive proposal can be made for Python 3.5 (as a new feature, this cannot go into existing stable versions).

Distutils is now deprecated (see PEP 632) and all tagged issues are being closed. From now until removal, only release blocking issues will be considered for distutils.

If this issue does not relate to distutils, please remove the component and reopen it. If you believe it still requires a fix, most likely the issue should be re-reported at https://github.com/pypa/setuptools