Phoenix builds with waf

wxPython Dev
1

Robin,

    until now I have been unable to use waf to build Phoenix, which
means that my (now old and scarred) computer goes on and on crunching
forever before I get the sources built into some binary I can use.

I have run the build process as:

python build.py waf_py

But I always get this output:

E:\Phoenix\wxPython\Phoenix>python build.py waf_py
Using C:\Python27\python.exe
3.2.3 (default, Apr 11 2012, 07:12:16) [MSC v.1500 64 bit (AMD64)]

Running command: waf_py
Checking for bin\waf-1.6.11...
C:\Python32\python.exe bin\waf-1.6.11 --prefix=/usr/local
--python=C:\Python32\python.exe --out=build_waf/2.7/release configure
build
Setting top to : E:\Phoenix\wxPython\Phoenix
Setting out to :
E:\Phoenix\wxPython\Phoenix\build_waf\2.7\release
Checking for program CL : C:\Program Files
(x86)\Microsoft Visual Studio 9.0\VC\BIN\CL.exe
Checking for program CL : C:\Program Files
(x86)\Microsoft Visual Studio 9.0\VC\BIN\amd64\CL.exe
Checking for program CL : C:\Program Files
(x86)\Microsoft Visual Studio 9.0\VC\BIN\CL.exe
Checking for program CL : C:\Program Files
(x86)\Microsoft Visual Studio 9.0\VC\BIN\amd64\CL.exe
Checking for program CL : C:\Program Files
(x86)\Microsoft Visual Studio 9.0\VC\BIN\CL.exe
Checking for program LINK : C:\Program Files
(x86)\Microsoft Visual Studio 9.0\VC\BIN\LINK.exe
Checking for program LIB : C:\Program Files
(x86)\Microsoft Visual Studio 9.0\VC\BIN\LIB.exe
Checking for program MT : C:\Program Files\Microsoft
SDKs\Windows\v7.0\Bin\X64\MT.exe
Checking for program RC : C:\Program Files\Microsoft
SDKs\Windows\v7.0\Bin\X64\RC.exe
Checking for program python : C:\Python32\python.exe
Checking for python version : (3, 2, 3, 'final', 0)
Checking for library python3.2 in $prefix/libs : not found
Checking for library python32 in $prefix/libs : not found
Checking for program
python3.2-config,python-config-3.2,python3.2m-config : not found
Checking for header Python.h
   : Could not find the python development headers
Checking for []
   : not found
The configuration failed
(complete log in E:\Phoenix\wxPython\Phoenix\build_waf\2.7\release\config.log)
Command 'C:\Python32\python.exe bin\waf-1.6.11 --prefix=/usr/local
--python=C:\Python32\python.exe --out=build_waf/2.7/release configure
build ' failed with exit code 1.
Finished command: waf_py (3.524s)

Which is somehow different from the output I can see from here:

http://buildbot.wxpython.org:8010/builders/build-win32-py27/builds/287/steps/shell/logs/stdio

Do you have any suggestion about what I may be doing wrong?

···

--
Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

# ------------------------------------------------------------- #
def ask_mailing_list_support(email):

    if mention_platform_and_version() and include_sample_app():
        send_message(email)
    else:
        install_malware()
        erase_hard_drives()
# ------------------------------------------------------------- #

2

Andrea Gavana wrote:

Robin,

     until now I have been unable to use waf to build Phoenix, which
means that my (now old and scarred) computer goes on and on crunching
forever before I get the sources built into some binary I can use.

I have run the build process as:

python build.py waf_py

But I always get this output:

E:\Phoenix\wxPython\Phoenix>python build.py waf_py
Using C:\Python27\python.exe
3.2.3 (default, Apr 11 2012, 07:12:16) [MSC v.1500 64 bit (AMD64)]

It looks like your Python 2.7 and 3.2 may have gotten mixed up. Build.py says it's using c:\Python27\python.exe but when it runs that command it appears to be running 3.2.3. When it gets to waf it looks like it could be similarly confused.

···

--
Robin Dunn
Software Craftsman

3

The issue appears also using Python 2.7, always with the same message:

Checking for header Python.h : Could not find the python development headers

But I do have c:\Python27\include in the INCLUDE environment variable.
Googling around, it appears to be an issue on 64 bit architectures,
for which waf will always throw this error irrespectively of whatever
I do.

Also, the fact that waf resets the LIB and INCLUDE environment
variables to empty strings before calling vcvarsall.bat is highly
questionable. I am stuck with the standard build then, and it's a pain
because it takes forever to rebuild everything every time there is an
SVN update (as cl.exe complains that the existing wxWidgets pdb files
- whatever the hell they are - have been compiled with a different
header - whatever that means).

···

On 11 July 2012 07:44, Robin Dunn wrote:

Andrea Gavana wrote:

Robin,

     until now I have been unable to use waf to build Phoenix, which
means that my (now old and scarred) computer goes on and on crunching
forever before I get the sources built into some binary I can use.

I have run the build process as:

python build.py waf_py

But I always get this output:

E:\Phoenix\wxPython\Phoenix>python build.py waf_py
Using C:\Python27\python.exe
3.2.3 (default, Apr 11 2012, 07:12:16) [MSC v.1500 64 bit (AMD64)]

It looks like your Python 2.7 and 3.2 may have gotten mixed up. Build.py
says it's using c:\Python27\python.exe but when it runs that command it
appears to be running 3.2.3. When it gets to waf it looks like it could be
similarly confused.

--
Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

# ------------------------------------------------------------- #
def ask_mailing_list_support(email):

    if mention_platform_and_version() and include_sample_app():
        send_message(email)
    else:
        install_malware()
        erase_hard_drives()
# ------------------------------------------------------------- #

4

Andrea Gavana wrote:

Robin,

      until now I have been unable to use waf to build Phoenix, which
means that my (now old and scarred) computer goes on and on crunching
forever before I get the sources built into some binary I can use.

I have run the build process as:

python build.py waf_py

But I always get this output:

E:\Phoenix\wxPython\Phoenix>python build.py waf_py
Using C:\Python27\python.exe
3.2.3 (default, Apr 11 2012, 07:12:16) [MSC v.1500 64 bit (AMD64)]

It looks like your Python 2.7 and 3.2 may have gotten mixed up. Build.py
says it's using c:\Python27\python.exe but when it runs that command it
appears to be running 3.2.3. When it gets to waf it looks like it could be
similarly confused.

The issue appears also using Python 2.7, always with the same message:

Checking for header Python.h : Could not find the python development headers

But I do have c:\Python27\include in the INCLUDE environment variable.
Googling around, it appears to be an issue on 64 bit architectures,
for which waf will always throw this error irrespectively of whatever
I do.

Also, the fact that waf resets the LIB and INCLUDE environment
variables to empty strings before calling vcvarsall.bat is highly
questionable.

This is strange, as waf's python tool uses code in distutils to get the info about the compiler and headers and so on the same way that is done for a build using setup.py, (except it doesn't do the same environment variables substitution that distutils does because that is a separate pass). I had to dig in to waf's python tool to diagnose an issue on Macs a few weeks ago, I'll do the same later this evening on Windows with a 64-bit Python and see if I can figure out a workaround. Worst case I can set up the configuration values myself for MSW builds in the wscript and not call waf's built-in python tool.

This probably won't make a difference, but just in case have you tried running waf without build.py? It should be something like:

   python bin/waf-1.6.11 --python=[full path to the python.exe to be used for the build] --out=[some build folder] configure build

I am stuck with the standard build then, and it's a pain
because it takes forever to rebuild everything every time there is an
SVN update (as cl.exe complains that the existing wxWidgets pdb files
- whatever the hell they are

Program DataBase files. They contain the debug info generated by the compiler.

- have been compiled with a different
header - whatever that means).

Usually the .h files that are #included by the C/C++ code. It's probably just warning you that the headers are newer than the debug info, and so the info is likely out of date in some way. If the code in the headers are not actually changed then that is probably okay. Otherwise there likely could be more problems than just out of date debug info and a recompile is called for. Since the command-line C/C++ compiler and nmake (and distutils for the Python parts of the build) don't have an easy way to generate and use dependency information then that usually means that a clean and rebuild is the best thing to do. However since MSVC is very fast that doesn't hurt nearly as much as it would with gcc...

···

On 7/11/12 2:48 PM, Andrea Gavana wrote:

On 11 July 2012 07:44, Robin Dunn wrote:

--
Robin Dunn
Software Craftsman

5

I've got a fix that I'm testing now. The waf settings for the compiler were being used instead of the distutils settings, and it just needed a little configuration tweak to tell it which platform to compile for. So basically when waf tried to build a little test program to check if Python.h could be found it was using the wrong compiler and linker and so it was failing. I'll commit the change once the test build has finished.

···

On 7/11/12 4:42 PM, Robin Dunn wrote:

On 7/11/12 2:48 PM, Andrea Gavana wrote:

On 11 July 2012 07:44, Robin Dunn wrote:

Andrea Gavana wrote:

Robin,

      until now I have been unable to use waf to build Phoenix, which
means that my (now old and scarred) computer goes on and on crunching
forever before I get the sources built into some binary I can use.

I have run the build process as:

python build.py waf_py

But I always get this output:

E:\Phoenix\wxPython\Phoenix>python build.py waf_py
Using C:\Python27\python.exe
3.2.3 (default, Apr 11 2012, 07:12:16) [MSC v.1500 64 bit (AMD64)]

It looks like your Python 2.7 and 3.2 may have gotten mixed up. Build.py
says it's using c:\Python27\python.exe but when it runs that command it
appears to be running 3.2.3. When it gets to waf it looks like it
could be
similarly confused.

The issue appears also using Python 2.7, always with the same message:

Checking for header Python.h : Could not find the python development
headers

But I do have c:\Python27\include in the INCLUDE environment variable.
Googling around, it appears to be an issue on 64 bit architectures,
for which waf will always throw this error irrespectively of whatever
I do.

--
Robin Dunn
Software Craftsman

6

Ah, thank you, it's so much faster and working now :slight_smile:

···

On 13 July 2012 00:57, Robin Dunn wrote:

On 7/11/12 4:42 PM, Robin Dunn wrote:

On 7/11/12 2:48 PM, Andrea Gavana wrote:

On 11 July 2012 07:44, Robin Dunn wrote:

Andrea Gavana wrote:

Robin,

      until now I have been unable to use waf to build Phoenix, which
means that my (now old and scarred) computer goes on and on crunching
forever before I get the sources built into some binary I can use.

I have run the build process as:

python build.py waf_py

But I always get this output:

E:\Phoenix\wxPython\Phoenix>python build.py waf_py
Using C:\Python27\python.exe
3.2.3 (default, Apr 11 2012, 07:12:16) [MSC v.1500 64 bit (AMD64)]

It looks like your Python 2.7 and 3.2 may have gotten mixed up. Build.py
says it's using c:\Python27\python.exe but when it runs that command it
appears to be running 3.2.3. When it gets to waf it looks like it
could be
similarly confused.

The issue appears also using Python 2.7, always with the same message:

Checking for header Python.h : Could not find the python development
headers

But I do have c:\Python27\include in the INCLUDE environment variable.
Googling around, it appears to be an issue on 64 bit architectures,
for which waf will always throw this error irrespectively of whatever
I do.

I've got a fix that I'm testing now. The waf settings for the compiler were
being used instead of the distutils settings, and it just needed a little
configuration tweak to tell it which platform to compile for. So basically
when waf tried to build a little test program to check if Python.h could be
found it was using the wrong compiler and linker and so it was failing.
I'll commit the change once the test build has finished.

--
Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

# ------------------------------------------------------------- #
def ask_mailing_list_support(email):

    if mention_platform_and_version() and include_sample_app():
        send_message(email)
    else:
        install_malware()
        erase_hard_drives()
# ------------------------------------------------------------- #