C:\somewhere> python
Python 2.4a3 (#56, Sep  2 2004, 20:50:21) ...

C:\somewhere> python setup.py build
running build_ext
Traceback (most recent call last):
  File "setup.py", line 19, in ?
    ext_modules = [
  File "C:\python24\lib\distutils\core.py", line 150, in 
setup
    dist.run_commands()
  File "C:\python24\lib\distutils\dist.py", line 991, in 
run_commands
    self.run_command(cmd)
  File "C:\python24\lib\distutils\dist.py", line 1011, in 
run_command
    cmd_obj.run()
  File "C:\python24\lib\distutils\command\build_ext.py", 
line 243, in run
    force=self.force)
  File "C:\python24\lib\distutils\ccompiler.py", line 1177, 
in new_compiler
    return klass (None, dry_run, force)
  File "C:\python24\lib\distutils\msvccompiler.py", line 
206, in __init__
    self.__macros = MacroExpander(self.__version)
  File "C:\python24\lib\distutils\msvccompiler.py", line 
112, in __init__
    self.load_macros(version)
  File "C:\python24\lib\distutils\msvccompiler.py", line 
128, in load_macros
    self.set_macro("FrameworkSDKDir", 
net, "sdkinstallrootv1.1")
  File "C:\python24\lib\distutils\msvccompiler.py", line 
118, in set_macro
    self.macros["$(%s)" % macro] = d[key]
KeyError: 'sdkinstallrootv1.1'

I suppose it's trying to tell me something, but I'm not 
sure what.

</F>

Logged In: YES 
user_id=29957

It looks (to me) like it's expecting you to have some
additional package (Framework SDK?) installed. The code in
question was added as part of the MSVC7 support - are you
building with MSVC6? 

Logged In: YES 
user_id=38376

If I'm using the wrong compiler, distutils should say so, 
instead of showing me a 10-level KeyError traceback...

Logged In: YES 
user_id=29957

Yep. Can you produce a small patch for this? I have no
access to MSVC 6 or 7 (in fact, my Windows box won't even
boot at the moment).

Logged In: YES 
user_id=488897

Note that the same error occurs with python setup.py install
(using Python 2.4b1):

C:\somewhere> python setup.py build
....
  File "c:\Python24\lib\distutils\msvccompiler.py", line
118, in set_macro
    self.macros["$(%s)" % macro] = d[key]
KeyError: 'sdkinstallrootv1.1'

Using MinGW for the compilation works:

C:\somewhere> python setup.py build --compiler=mingw32
....
compiles without errors. However, the install still fails:

C:\somewhere> python setup.py install
  File "c:\Python24\lib\distutils\msvccompiler.py", line
118, in set_macro
    self.macros["$(%s)" % macro] = d[key]
KeyError: 'sdkinstallrootv1.1'

Logged In: YES 
user_id=539787

I get the same message trying to build PIL with 2.4rc1,
having installed the VC++ toolkit (free command line
compiler), so it's not a problem of VS 6.  I assume/fear
that the .NET SDK framework needs to be installed.

Logged In: YES 
user_id=539787

I get the same message trying to build PIL with 2.4rc1,
having installed the VC++ toolkit (free command line
compiler), so it's not a problem of VS 6.  I assume/fear
that the .NET SDK framework needs to be installed.

Logged In: YES 
user_id=539787

I get the same message trying to build PIL with 2.4rc1,
having installed the VC++ toolkit (free command line
compiler), so it's not a problem of VS 6.  I assume/fear
that the .NET SDK framework needs to be installed.

Logged In: NO 

I get the same message trying to build PIL with 2.4rc1,
having installed the VC++ toolkit (free command line
compiler), so it's not a problem of VS 6.  I assume/fear
that the .NET SDK framework needs to be installed.

Logged In: YES 
user_id=539787

Please forgive my previous quadruple followup.

This page ( http://www.vrplumber.com/programming/mstoolkit/
) is relevant.  The message about sdkinstallroot1.1 should
be related to the .NET Framework SDK v1.1 not being installed.

I would wrap the offending line in load_macros function and
throw an exception with more informative args.  Do you want
me to?

PS I attempted to "pass" the failing statement in line 128
(in the load_macros function); building Imaging complains
that VS 7.1 is not installed.

Logged In: YES 
user_id=38376

"I would wrap the offending line in load_macros function and
throw an exception with more informative args.  Do you want
me to?"

Makes sense to me.

Logged In: YES 
user_id=539787

Please check patch 1071739.

The updated report is:

D:\SRC\Imaging-1.1.5b1>python setup.py build_ext -i
running build_ext
error: The .NET Framework SDK needs to be installed before
building extensions for Python.

Logged In: YES 
user_id=488897

The patch probably works fine for Microsoft users, but now
gcc users get an unhelpful error message:

$ /cygdrive/c/Python24/python setup.py build --compiler=mingw32
... runs fine, using gcc compiler ...
... now let's try to make the installer:
$ /cygdrive/c/Python24/python setup.py bdist_wininst
running bdist_wininst
running build
running build_py
running build_ext
error: The .NET Framework SDK needs to be installed before
building extensions for Python.

I'm not sure why distutils is running msvccompiler.py. To
check if all components have been compiled and are ready to
be included into the installer, it shouldn't matter which
compiler was used during the build step.

Logged In: YES 
user_id=38376

The patch only changed the error message; earlier versions 
gave a KeyError exception.  Are you really claiming that this 
worked in earlier 2.4 releases?

Does it work if you pass in the --compiler switch to 
bdist_wininst?

Logged In: YES 
user_id=488897

> Are you really claiming that this worked in earlier 2.4
releases?

No, it didn't work for any of the 2.4 releases, but it did
work for Python 2.3 and 2.2:

$ /cygdrive/c/Python23/python setup.py build --compiler=mingw32
... compiles the extension module using gcc
$ /cygdrive/c/Python23/python setup.py bdist_wininst
running bdist_wininst
running build
running build_py
running build_ext
installing to build\bdist.win32\wininst
running install_lib
.... creates the installer.

> Does it work if you pass in the --compiler switch to 
bdist_wininst?

No, it doesn't, I get the following error message:

$ /cygdrive/c/Python24/python setup.py bdist_wininst
--compiler=mingw32
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2
[cmd2_opts] ...]
   or: setup.py --help [cmd1 cmd2 ...]
   or: setup.py --help-commands
   or: setup.py cmd --help

error: option --compiler not recognized

This makes sense, because no compilation is needed to create
the installer.

From looking at msvccompiler.py, it looks like the problem
is that self.__macros = MacroExpander(self.__version) is
called when creating the MSVCCompiler, before we know if
anything is left that still needs to be compiled. 

A solution might be to leave self.__macros None in __init__,
and check it in the compile function. If it is still None
there, we can make the call to MacroExpander then. Users of
gcc will not need to run MSVCCompiler's compile function, so
they will not run into MacroExpander.

There is one remaining problem in __init__:

if len (self.__paths) == 0:
    raise DistutilsPlatformError, \
          ("Python was built with version %s of Visual Studio, "
           "and extensions need to be built with the same "
           "version of the compiler, but it isn't
installed." % self.__version)

Is this true? It would imply that gcc can't be used at all.
However, extension modules built with gcc seem to work
correctly with Python 2.4, as far as I can tell.

Logged In: YES 
user_id=38376

> This makes sense, because no compilation is needed to 
create the installer.

That's an incorrect assumption: bdist_wininst does a 
full "build" before it builds the installer.  All standard distutils 
commands work this way; you don't have to run them in any 
specific order.

I suggest you open a new, more specific bug ("bdist_wininst 
relies on msvccompiler"), and follow up with a message to the 
python-dev.

It might be too late for 2.4 (it's been this way through the 
alpha and beta releases, without anyone noticing), but 
maybe some distutils expert can come up with a workaround 
(or explain how this really is supposed to work).

Logged In: YES 
user_id=488897

>I suggest you open a new, more specific bug ("bdist_wininst 
> relies on msvccompiler"), and follow up with a message to
> the python-dev.

Well this is a severe bug in Python 2.4: Users of compilers
other than Microsoft can no longer build extension modules
for Python on Windows. (Well they can build one, but they
cannot install it nor create a binary installer). So I wrote
a patch for msvccompiler.py and submitted it to sourceforge
(see patch 1075887). Could you do me a favor and have a look
at this patch (or have somebody else look at it)? There are
lots of patches for Python 2.4 already, some very old, and
I'm worried that it may take a long time before this gets fixed.

Logged In: YES 
user_id=11105

The solution or workaround is to either run
'python setup.py build --compiler=whatever bdist_wininst'
or insert 'compiler=whatever' in a setup.cfg file.

I have explained this several times, IMO something should be
added to the distutils documentation about this (but I don't
have the time).

Logged In: YES 
user_id=488897

> python setup.py build --compiler=whatever bdist_wininst

This worked for me (with Python 2.4 final, without any
patch). I wasn't aware that this simple solution existed.
You're right, this should be in the documentation. Many thanks.

Logged In: YES 
user_id=38376

Original issue fixed in 2.4 final.