No, it's the job of the CCompiler classes to ensure that the files they are about to write can be written, ie. that os.path.dirname(output_file) exists before running the compile/link/whatever that attempts to create output_file.
Yes, the problem is that during the link (i.e. when we're actually making the Windows DLL) it actually creates (well, tries to create) the following *three* files: build\lib.win32\MyExtensionName.pyd build\temp.win32\Release\MyExtensionName.lib build\temp.win32\Release\MyExtensionName.exp For the record, here's what my distutils-conjured link line looks like: link.exe /DLL /nologo /INCREMENTAL:NO /LIBPATH:../dtf \ /LIBPATH:D:\Progra~1\Python\libs DTF.lib \ build\temp.win32\Release\core_wrap.obj \ /OUT:build\lib.win32\dtf\core.pyd /export:initcore \ /IMPLIB:build\temp.win32\Release\dtf\core.lib You are correct that link_shared_object() takes care of mkpath'ing the output directory for the DLL itself but it does *not* create the needed directories for the scratch files ("core.lib" and "core.exp"). So perhaps the patch that I originally suggested for build_ext.py should be moved into link_shared_object() instead. It doesn't matter to me as long as somebody creates that directory before we try to dump files into it ;) Lyle