Compiling wxPython Phoenix on Windows 10 64 bit with VS2015 and Python 35

wxPython Users
1

I tried to compile wxPython using Python35 and VS2015.
The build.py script have some issues with bytes needing encoding:

File “build.py”, line 666, in checkCompiler
os.environ[‘PATH’] = bytes(env[‘path’])
TypeError: string argument without an encoding

so I supposed that it was a Python 2 script. So I tried using python 2.7:

\python27\python.exe build.py --python=\python35\python.exe build

But I get:

Command ‘"\python35\python.exe" -c “import sys; print(sys.version[:3])”’ failed with exit code 1.
'\python35\python.exe" -c "import’is not recognized as an internal or external command, operable program or batch file.

I tried the batch file:

set PATH=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64;C:\Python35;C:\cygwin\bin;C:\Python35\Scripts
set LIB=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib\amd64;
set INCLUDE=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include;C:\Python35\include

python -u build.py 3.5 clean dox touch etg --nodoc sip build_wx build_py

But I get:

Running command: clean_wx
Command ‘“C:\Python35\python.exe” -c “import distutils.msvc9compiler as msvc; mc = msvc.MSVCCompiler(); mc.initialize(); print(mc.cc)”’ failed with exit code 1.
Traceback (most recent call last):
File “”, line 1, in
File “C:\Python35\lib\distutils\msvc9compiler.py”, line 374, in initialize
vc_env = query_vcvarsall(VERSION, plat_spec)
File “C:\Python35\lib\distutils\msvc9compiler.py”, line 290, in query_vcvarsall
raise ValueError(str(list(result.keys())))
ValueError: [‘path’, ‘include’, ‘lib’]

In Python 3.5 the msvc9compiler was removed so I tried to change script to use msvccompiler (it reads the registry to find the appropriate compiler) but the same error:

Running command: build_wx
Command ‘“C:\Python35\python.exe” -c “import distutils.msvccompiler as msvc; mc = msvc.MSVCCompiler(); mc.initialize(); print(mc.cc)”’ failed with exit code 1.
Traceback (most recent call last):
File “”, line 1, in
File “C:\Python35\lib\distutils\msvc9compiler.py”, line 374, in initialize
vc_env = query_vcvarsall(VERSION, plat_spec)
File “C:\Python35\lib\distutils\msvc9compiler.py”, line 290, in query_vcvarsall
raise ValueError(str(list(result.keys())))
ValueError: [‘path’, ‘include’, ‘lib’]

It seems like the VS2015 cannot be found.
I never tried this before so I am completely lost here.

2

Unfortunately you tried a bit too early. I wanted to post a summary this week.
It took me some time last week to build Phoenix for Python 3.5 in 32 and 64 bit.
distutils.msvc9compiler is still the right version.
I hope I did not forget anything relevant in the instructions below. The rest of the week I'm probably not online too often, but I will try to support you.
I did use a more recent version of sip, but I would assume that the standard version is still OK.
I did only do a basic verification, as my main version is still Python 3.4 32 bit.

···

Am 24.11.2015 um 13:12 schrieb Airton Granero:

I tried to compile wxPython using Python35 and VS2015.

==================================
Prerequisites:

  - Python 2.7 installed for the build script
  - Cygwin installed
  - Visual Studio 2015 Community Edition installed; my Express edition had only 32 bit compilers
   The vcvarsall.bat should be at "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat"
   The path "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin" should exist and cl.exe should be there.

Additional prerequisites for 64 bit:
  - Check for 64 compiler:
   The path "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64" should exist and cl.exe should be there
   If not try: New Project -> Templates -> Visual C++ -> MFC -> Install Microsoft Foundation Classes for C++

  - wxPython Phoenix downloaded from git and git submodule initialized.
     The commands should probably be:

     git submodule init
     git submodule update

The downloaded version of wxWidgets is not the most recent one.

==================================
Required modifications:
The Visual Studio 2015 compiler, aka version 14 is not known to older versions of wxWidgets and to wxPython.

wxWidgets: apply these patches:
http://trac.wxwidgets.org/attachment/ticket/16854/msw_vc14_compiler_fixes.diff

wxPython:

Add compiler version 14 to these two scripts:
   Phoenix\ext\wxWidgets\build\tools\build-wxwidgets.py
   Phoenix\buildtools\config.py

def getVisCVersion():
     text = getoutput("cl.exe")
     if 'Version 13' in text:
         return '71'
     if 'Version 15' in text:
         return '90'
     if 'Version 16' in text:
         return '100'
     if 'Version 19' in text:
         return '140'
     # TODO: Add more tests to get the other versions...
     else:
         return 'FIXME'

Modify Phoenix/wscript configure function to get the compiler version number from distutily.msvc9compiler:
(I have verified this modification only with Python 3.4. and 3.5.)

def configure(conf):
     if isWindows:
         # For now simply choose the compiler version based on the Python
         # version. We have a chicken-egg problem here. The compiler needs to
         # be selected before the Python stuff can be configured, but we need
         # Python to know what version of the compiler to use.
         # TODO: Fix this

         import distutils.msvc9compiler
         msvc_version = str( distutils.msvc9compiler.get_build_version() )
         #msvc_version = '9.0' #conf.options.msvc_ver
         #if conf.options.python and ('33' in conf.options.python or
                                     #'34' in conf.options.python or
                                     #'35' in conf.options.python):
             #msvc_version = '10.0'

         conf.env['MSVC_VERSIONS'] = ['msvc ' + msvc_version]
         conf.env['MSVC_TARGETS'] = [conf.options.msvc_arch]
         conf.load('msvc')

Check whether the doxygen shell script has the correct line endings for Cygwins bash shell (LF only, not CR+LF):
Phoenix\ext\wxWidgets\docs\doxygen\regen.sh

If you run into encoding problems, you may also want to change Phoenix/buildtools/config.py:
In runcmd(...) add an 'ignore':
  output = output.decode('utf-8', 'ignore') # TODO: is utf-8 okay here?

==================================
Optional modifications:
In the older wx version is a bug which prevents multiple blocks to be selected in the grid.
This patch fixes the problem:

==================================
Build:

Open a cmd window (not Cygwin!)
Go to the Phoenix path.
Enter command (Footnote 1):
   chcp 1252

For building (without installation) the command is as follows:
   D:/Python/Python27/python.exe build.py dox etg --nodoc sip build --python=D:/Python/Python35/python.exe

(Of course you need to set your paths accordingly. Python 2.7 is required for the build script, the other version is the target.)

When the build is finished, you should see a message like this:
   ------------ BUILD FINISHED ------------
   To use wxPython from the build folder (without installing):
    - Set your PYTHONPATH variable to D:\Python\Sources34\Phoenix.

You may do as suggested or call the build script again with the install command.

==================================
Footnotes:
(1)
Otherwise the waf build engine may have problems with Visual C compilers outputting non-ASCII characters, which can e.g. happen with non-english installations.
You would just get the error message "msvc: Impossible to find a valid architecture for building (in setup_msvc)", unless you apply the patch at https://github.com/waf-project/waf/commit/0e03aec82dfabefc9d104104fb0c18916a8db74b .
If you apply the patch, the build would still fail, but at least you would get a more meaningful error message.

Regards,

Dietmar

3

I forgot one modification in the previous post:
modify the touch command in wscript:
open(...) will do the same as the touch command, I think.

def copyFileToPkg(task):
     from distutils.file_util import copy_file
     from buildtools.config import opj
     src = task.inputs[0].abspath()
     tgt = task.outputs[0].abspath()
     #task.exec_command('touch %s' % tgt)
     open(tgt, "wb").close()
     tgt = opj(cfg.PKGDIR, os.path.basename(src))
     copy_file(src, tgt, verbose=1)
     return 0

Regards,

Dietmar

4

I got to compile it.

I already cygwin.

But it seem to have some problems with the script. if you don’t set the path and pass the --python parameter this way:

\python27\python build.py --python=\python35\python.exe build

You got the error:

Command ‘"\python35\python.exe" -c “import sys; print(sys.version[:3])”’ failed with exit code 1.

‘\python35\python.exe" -c "import’ is not recognized as an internal or external command, operable program or batch file.

I have corrected it by removing the double quotes around the command in the runcmd statements in build.py (curiously this works in Python 3.5).

Then I got this error

C:\Program Files (x86)\Windows Kits\10\include\10.0.10150.0\ucrt\stdio.h(1927): fatal error C1189: #error: Macro definition of snprintf conflicts with Standard Library function declaration.

I corrected it in \src\tiff\libtiff\tif_config.h - line 367

#define snprintf _snprintf

that I changed to (by sugestion in
https://forums.wxwidgets.org/viewtopic.php?t=40491):

#if (defined(_MSC_VER) && (_MSC_VER < 1900))

  #define snprintf _snprintf`
``

`
#endif`

**I got erros now because of the spaces in the path to source so I changed build.py from

# Run waf to perform the builds
    pwd = pushDir(phoenixDir())
    cmd = '%s %s %s configure build %s' % (PYTHON, waf, ' '.join(build_options), options.extra_waf)
    runcmd(cmd)

to (putting double quotes):

# Run waf to perform the builds
    pwd = pushDir(phoenixDir())
    cmd = '%s "%s" %s configure build %s' % (PYTHON, waf, ' '.join(build_options), options.extra_waf)
    runcmd(cmd)

Now I got the error:

msvc: Impossible to find a valid architecture for building (in setup_msvc)

def configure(conf):   

    if isWindows:       

        # For now simply choose the compiler version based on the Python

        # version. We have a chicken-egg problem here. The compiler needs to

        # be selected before the Python stuff can be configured, but we need

        # Python to know what version of the compiler to use.

        # TODO: Fix this

        msvc_version = '9.0' #conf.options.msvc_ver

        if conf.options.python and ('33' in conf.options.python or

                                    '34' in conf.options.python):

            msvc_version = '10.0'

....

That was corrected changing wscript in this place

 by adding the line

if conf.options.python and ('35' in conf.options.python):

msvc_version = '14.0'

#if __VISUALC__ < 1100

#   error "This Visual C++ version is too old and not supported any longer."

#elif __VISUALC__ < 1200

#   define __VISUALC5__

#elif __VISUALC__ < 1300

#   define __VISUALC6__

#elif __VISUALC__ < 1400

#   define __VISUALC7__

#elif __VISUALC__ < 1500

#   define __VISUALC8__

#elif __VISUALC__ < 1600

#   define __VISUALC9__

#elif __VISUALC__ < 1700

#   define __VISUALC10__

#elif __VISUALC__ < 1800

#   define __VISUALC11__

#elif __VISUALC__ < 1900

#   define __VISUALC12__

#else

#   pragma message("Please update wx/compiler.h to recognize this VC++ version")

#endif

Compilation gave me some warnings

Please update wx/compiler.h to recognize this VC++ version

that I corrected changing wxWidgets\inclue\wx\compiler.h :

by adding the line (after thelast elif of course)

#elif __VISUALC__ < 2000

#   define __VISUALC14__

The build ended with the error:

'touch' is not recognized as an internal or external command, operable program or batch file.

...

missing file: 'mypath\\wxPython_Phoenix-3.0.3.dev1830+0b5f910\\build\\waf\\3.5\\x64\\release\\pkg.siplib'

What happened is that my cygwin wasn't in path, so I did:

set PATH=%PATH%;C:\cygwin64\bin

But the last error was still happening:

missing file: 'mypath\\wxPython_Phoenix-3.0.3.dev1830+0b5f910\\build\\waf\\3.5\\x64\\release\\pkg.siplib'

that was because of the space in mypath this was corrected by changing wscript in line

task.exec_command('touch %s' % tgt)
 

to

task.exec_command('touch "%s"' % tgt)

And then it worked!!!!!

But now I am thinking how to create the wheel file.
I will post the diff files after I make sense of all this as my priority was to make the build work
5

I am curious.
When I hadn’t cygwin in my path the only place I got an error was in touch.
Is this the only place cygwin is needed?
If so your change is very welcome. I already had cygwin, but It can be a little hard to install.

Another thing that is that in build.py we have in setPythonVersion function:

       if 'cygdrive' in TOOLS:
            TOOLS = runcmd('c:/cygwin/bin/cygpath -w '+TOOLS, True, False)

in Windows if we get the environment variable TOOLS function this assumes cygwin is installed at c:/cygwin/bin/cygpath which may be not the case (in 64 bit machines it is c:/cygwin64/).

···

On Tuesday, November 24, 2015 at 8:16:28 PM UTC-2, Dietmar Schwertberger wrote:

I forgot one modification in the previous post:

modify the touch command in wscript:

open(…) will do the same as the touch command, I think.

def copyFileToPkg(task):

 from distutils.file_util import copy_file

 from buildtools.config   import opj

 src = task.inputs[0].abspath()

 tgt = task.outputs[0].abspath()

 #task.exec_command('touch %s' % tgt)

 open(tgt, "wb").close()

 tgt = opj(cfg.PKGDIR, os.path.basename(src))

 copy_file(src, tgt, verbose=1)

 return 0

Regards,

Dietmar

6

I did modify the wscript not to call the touch command, but to use
Python code instead.
The doxygen command uses a shell script regen.sh. For this it’s
easier to have the cygwin environment with the bash shell.
It would be possible to use regen.bat, but this would require
modification as build.py calls the doxygen command with the revision
number included into the exe name.
But the build script itself should better be run in a Windows cmd
window, not in cygwin.
Try from a cmd window first. On my 64 bit Windows, cygwin is still
at c:\cygwin, but I’m not sure whether my cygwin is 32 or 64 bit.
I’m not sure whether the cygpath is called at all from the build.py
script in a cmd window.
Of course the issue may still be there for calling the bash shell.
Regards,
Dietmar

···

Am 30.11.2015 um 15:43 schrieb Airton
Granero:

I am curious.

    When I hadn't cygwin in my path the only place I got an error

was in touch.

Is this the only place cygwin is needed?

    If so your change is very welcome. I already had cygwin, but It

can be a little hard to install.

    Another thing that is that in build.py we have in

setPythonVersion function:

                 if 'cygdrive' in TOOLS:

                      TOOLS = runcmd('c:/cygwin/bin/cygpath -w

'+TOOLS, True, False)

              in Windows if we get the

environment variable TOOLS function this assumes
cygwin is installed at c:/cygwin/bin/cygpath
which may be not the case (in 64 bit machines it is c:/cygwin64/).

7

Another thing.
How to create the wheel package?
If i try

   python setup.py bdist_wheel

I just get the error:

   error: invalid command 'bdist_wheel'

I have wheel instaled, and the setup script has references to building a wheel file.
If I make:

   python setup.py --help

I see no reference to creating a wheel. What I am doing wrong?

And by the way thanks.

···

On Monday, November 30, 2015 at 3:19:03 PM UTC-2, Dietmar Schwertberger wrote:

  Am 30.11.2015 um 15:43 schrieb Airton > Granero:

I am curious.

    When I hadn't cygwin in my path the only place I got an error

was in touch.

I did modify the wscript not to call the touch command, but to use

Python code instead.

Is this the only place cygwin is needed?

    If so your change is very welcome. I already had cygwin, but It

can be a little hard to install.

The doxygen command uses a shell script regen.sh. For this it's

easier to have the cygwin environment with the bash shell.

It would be possible to use regen.bat, but this would require

modification as build.py calls the doxygen command with the revision
number included into the exe name.

But the build script itself should better be run in a Windows cmd

window, not in cygwin.

    Another thing that is that in build.py we have in

setPythonVersion function:

                 if 'cygdrive' in TOOLS:

                      TOOLS = runcmd('c:/cygwin/bin/cygpath -w

'+TOOLS, True, False)

              in Windows if we get the

environment variable TOOLS function this assumes
cygwin is installed at c:/cygwin/bin/cygpath
which may be not the case (in 64 bit machines it is c:/cygwin64/).

Try from a cmd window first. On my 64 bit Windows, cygwin is still

at c:\cygwin, but I’m not sure whether my cygwin is 32 or 64 bit.

I'm not sure whether the cygpath is called at all from the  build.py

script in a cmd window.

Of course the issue may still be there for calling the bash shell.





Regards,



Dietmar
8

I did never build a wheel.
From build.py:
     bdist_wheel Build a Python wheel. Requires magic.

It seems that the up-to-date documentation is here: Python Packaging User Guide

The wheel package / distutils plugin is not installed by default:
     "D:\Python\Python35\Scripts\pip3.5.exe" install wheel

With wheel installed, the bdist_wheel does work for me:

     D:/Python/Python27/python.exe build.py bdist_wheel --python=D:/Python/Python35/python.exe

     Running command: bdist_wheel
     "D:\Python\Python35\python.exe" setup.py bdist_wheel --skip-build
     Finished command: bdist_wheel (8.166s)
     Done!

I don't have much experience with wheels, especially not with local wheels.
Does this work for you? I just tried Python 3.5 32 bit.

Regards,

Dietmar

···

Am 30.11.2015 um 20:16 schrieb Airton Granero:

I see no reference to creating a wheel. What I am doing wrong?

9

This command works ant the whl file is generated (i was trying with setup.py not build.py)
But when I install it with

pip install wxPython_Phoenix-3.0.3.dev1830+0b5f910-cp35-none-win_amd64.whl

it works, but when I enter python and do

import wx

I get:

Python 3.5.0 (v3.5.0:374f501f4567, Sep 13 2015, 02:27:37) [MSC v.1900 64 bit (AMD64)] on win32
Type “help”, “copyright”, “credits” or “license” for more information.

import wx
Traceback (most recent call last):
File “”, line 1, in
File “C:\Python35\lib\site-packages\wx_init_.py”, line 17, in
from wx.core import *
ImportError: No module named ‘wx.core’

···

On Monday, November 30, 2015 at 6:23:14 PM UTC-2, Dietmar Schwertberger wrote:

Am 30.11.2015 um 20:16 schrieb Airton Granero:

I see no reference to creating a wheel. What I am doing wrong?

I did never build a wheel.

From build.py:

 bdist_wheel   Build a Python wheel.  Requires magic.

It seems that the up-to-date documentation is here:
https://packaging.python.org/en/latest/

The wheel package / distutils plugin is not installed by default:

 "D:\Python\Python35\Scripts\pip3.5.exe" install wheel

With wheel installed, the bdist_wheel does work for me:

 D:/Python/Python27/python.exe build.py bdist_wheel

–python=D:/Python/Python35/python.exe

 Running command: bdist_wheel

 "D:\Python\Python35\python.exe" setup.py bdist_wheel --skip-build

 Finished command: bdist_wheel (8.166s)

 Done!

I don’t have much experience with wheels, especially not with local wheels.

Does this work for you? I just tried Python 3.5 32 bit.

Regards,

Dietmar

10

Well, build.py just calls setup.py anyway.
Did you do a full build with build.py before? It seems to me that
bdist_wheel just collects each and everything from the wx directory
which was built before.
(If anyone is building for multiple Python versions: a clean is
required between building the wheels as otherwise all versions are
in the .whl)
The .whl file is just a zip file. Do you have the file wx\core.py
inside?
Regards,
Dietmar

···

Am 30.11.2015 um 22:14 schrieb Airton
Granero:

    This command works ant the whl file is generated (i

was trying with setup.py
not build.py)

it works, but when I enter python and do

11

Yes. I did a

\python27\python.exe build.py --python=\python35\python.exe clean build

and then

c:/python27/python.exe build.py bdist_wheel --python=c:/python35/python.exe

and then

pip install wxPython_Phoenix-3.0.3.dev1830+0b5f910-cp35-none-win_amd64.whl

with the already exposed result. Maybe there is something wrong in the build.

···

On Monday, November 30, 2015 at 7:27:28 PM UTC-2, Dietmar Schwertberger wrote:

  Am 30.11.2015 um 22:14 schrieb Airton > Granero:

    This command works ant the whl file is generated (i

was trying with setup.py
not build.py)

Well, build.py just calls setup.py anyway.

it works, but when I enter python and do

Did you do a full build with build.py before? It seems to me that

bdist_wheel just collects each and everything from the wx directory
which was built before.

(If anyone is building for multiple Python versions: a clean is

required between building the wheels as otherwise all versions are
in the .whl)

The .whl file is just a zip file. Do you have the file wx\core.py

inside?

Regards,



Dietmar
12

I would suggest a full build.py run including the commands "dox etg --nodoc sip build".
Even though, this should not be required, I think that the build.py script does not manage/check some of the interim dependencies 100% correct.

Regards,

Dietmar

···

Am 30.11.2015 um 23:09 schrieb Airton Granero:

with the already exposed result. Maybe there is something wrong in the build.

13

Thanks Deitmar you are a great help.
I did what you said.

I gave this command (taking --nodo and sip out give the same result).

c:/python27/python.exe build.py clean build dox etg --nodoc sip bdist_wheel --python=c:/python35/python.exe

and I got at the end

------------ BUILD FINISHED ------------

To use wxPython from the build folder (without installing):

  • Set your PYTHONPATH variable to C:\Users\agranero\Downloads\4 Programming\wxPython_Phoenix-3.0.3.dev1830+0b5f910.

Finished command: build_py (13m27.264s)

Finished command: build (20m1.341s)

Running command: dox

Checking for C:\Users\agranero\Downloads\4 Programming\wxPython_Phoenix-3.0.3.dev1830+0b5f910\bin\doxygen-1.8.8-win32.exe…

Not found. Attempting to download…

Connection successful…

Data downloaded…

Checking for C:\Users\agranero\Downloads\4 Programming\wxPython_Phoenix-3.0.3.dev1830+0b5f910\bin\doxygen-1.8.8-win32.exe…

Command ‘c:/cygwin/bin/cygpath -u C:/Users/agranero/Downloads/4 Programming/wxPython_Phoenix-3.0.3.dev1830+0b5f910/bin/doxygen-1.8.8-win32.exe’ failed with exit code 1.

O sistema não pode encontrar o caminho especificado.

Finished command: dox (9.72s)

as I foresaw the hardcoded paths were a problem, so I changed them (cygwin64) and tried again:

------------ BUILD FINISHED ------------

To use wxPython from the build folder (without installing):

  • Set your PYTHONPATH variable to C:\Users\agranero\Downloads\4 Programming\wxPython_Phoenix-3.0.3.dev1830+0b5f910.

Finished command: build_py (13m22.124s)

Finished command: build (19m25.472s)

Running command: dox

Checking for C:\Users\agranero\Downloads\4 Programming\wxPython_Phoenix-3.0.3.dev1830+0b5f910\bin\doxygen-1.8.8-win32.exe…

c:/cygwin64/bin/bash.exe -l -c “cd C:/Users/agranero/Downloads/4 Programming/wxPython_Phoenix-3.0.3.dev1830+0b5f910/ext/wxWidgets/docs/doxygen && ./regen.sh xml”

/usr/bin/bash: line 0: cd: C:/Users/agranero/Downloads/4: Not a directory

Command ‘c:/cygwin64/bin/bash.exe -l -c “cd C:/Users/agranero/Downloads/4 Programming/wxPython_Phoenix-3.0.3.dev1830+0b5f910/ext/wxWidgets/docs/doxygen && ./regen.sh xml”’ failed with exit code 1.

Finished command: dox (1.975s)

Again spaces in the path pose a problem. I changed build.py the line:

cmd = ‘c:/cygwin64/bin/bash.exe -l -c “cd %s && ./regen.sh %s”’ % (d, arg)

to:

cmd = ‘c:/cygwin64/bin/bash.exe -l -c “cd “%s” && ./regen.sh %s”’ % (d, arg)

and tried again. Still the same error because we have double quotes inside double quotes, changed to simplle quotes ecaping them:

cmd = ‘c:/cygwin64/bin/bash.exe -l -c “cd '%s' && ./regen.sh %s”’ % (d, arg)

now the error changed:

------------ BUILD FINISHED ------------

To use wxPython from the build folder (without installing):

  • Set your PYTHONPATH variable to C:\Users\agranero\Downloads\4 Programming\wxPython_Phoenix-3.0.3.dev1830+0b5f910.

Finished command: build_py (16m33.784s)

Finished command: build (23m56.631s)

Running command: dox

Checking for C:\Users\agranero\Downloads\4 Programming\wxPython_Phoenix-3.0.3.dev1830+0b5f910\bin\doxygen-1.8.8-win32.exe…

c:/cygwin64/bin/bash.exe -l -c “cd ‘C:/Users/agranero/Downloads/4 Programming/wxPython_Phoenix-3.0.3.dev1830+0b5f910/ext/wxWidgets/docs/doxygen’ && ./regen.sh xml”

cat: doxygen.log: No such file or directory

./regen.sh: line 208: cd: /cygdrive/c/Users/agranero/Downloads/4: Not a directory

Command ‘c:/cygwin64/bin/bash.exe -l -c “cd ‘C:/Users/agranero/Downloads/4 Programming/wxPython_Phoenix-3.0.3.dev1830+0b5f910/ext/wxWidgets/docs/doxygen’ && ./regen.sh xml”’ failed with exit code 1.

Finished command: dox (1.852s)

I changed the \ext\wxWidgets\docs\doxygen\regen.sh from:

return to the original folder from which this script was launched

cd $current

to put double quotes around the path (again the space on the path):

return to the original folder from which this script was launched

cd “$current”

obtaining:

------------ BUILD FINISHED ------------

To use wxPython from the build folder (without installing):

  • Set your PYTHONPATH variable to C:\Users\agranero\Downloads\4 Programming\wxPython_Phoenix-3.0.3.dev1830+0b5f910.

Finished command: build_py (14m30.721s)

Finished command: build (21m0.870s)

Running command: dox

Checking for C:\Users\agranero\Downloads\4 Programming\wxPython_Phoenix-3.0.3.dev1830+0b5f910\bin\doxygen-1.8.8-win32.exe…

c:/cygwin64/bin/bash.exe -l -c “cd ‘C:/Users/agranero/Downloads/4 Programming/wxPython_Phoenix-3.0.3.dev1830+0b5f910/ext/wxWidgets/docs/doxygen’ && ./regen.sh xml”

Finished command: dox (2.739s)

Running command: etg

Traceback (most recent call last):

File “build.py”, line 1655, in 

main(sys.argv[1:])

File “build.py”, line 171, in main

function(options, args)

File “build.py”, line 775, in cmd_etg

assert os.path.exists(cfg.DOXY_XML_DIR), "Doxygen XML folder not found: " + cfg.DOXY_XML_DIR

AssertionError: Doxygen XML folder not found: C:\Users\agranero\Downloads\4 Programming\wxPython_Phoenix-3.0.3.dev1830+0b5f910\ext\wxWidgets\docs/doxygen/out/xml

Finished command: etg (0.20s)

Now I am stuck. I think I know what Doxigen does, but I am not experienced with it.
It seems the build finished, but something got wrong for dox generating the xml needed for etg scripts to generate files used by sip to generate the bindings (am I right?).

before constructing the wheel file.

···

On Monday, November 30, 2015 at 8:24:56 PM UTC-2, Dietmar Schwertberger wrote:

Am 30.11.2015 um 23:09 schrieb Airton Granero:

with the already exposed result. Maybe there is something wrong in the
build.

I would suggest a full build.py run including the commands “dox etg
–nodoc sip build”.

Even though, this should not be required, I think that the build.py
script does not manage/check some of the interim dependencies 100% correct.

Regards,

Dietmar

14

PS I created the xml folder. Now I am in the next error in sip. (spaces in path again).

···

On Monday, November 30, 2015 at 8:24:56 PM UTC-2, Dietmar Schwertberger wrote:

Am 30.11.2015 um 23:09 schrieb Airton Granero:

with the already exposed result. Maybe there is something wrong in the
build.

I would suggest a full build.py run including the commands “dox etg
–nodoc sip build”.

Even though, this should not be required, I think that the build.py
script does not manage/check some of the interim dependencies 100% correct.

Regards,

Dietmar

15

Why not take the easiest way?
  - a project directory without spaces in the path
  - 32 bit cygwin at c:\cygwin (or rename cygwin64 directory)
  - use Windows cmd window instead of cygwin shell

The problems with spaces in path should of course be fixed, but as long as there's no way to update the Github repository with the fixes, it does not help too much as with the next revision you will need to apply the changes again...
I've just bought a book about git. So hopefully I will find out how to fork Phoenix including the modifications on Phoenix and wx (building, ActiveX, MetafileDC, MediaCtrl) such that we have a common work base. (Or maybe Robin will find the time to merge the pull requests.) For versions based on wx >3.0.2 some modifications to the build tools are required as the build process of wx has changed, so for some time we should stick to a modified 3.0.2.

Yes, Doxygen takes the header files from ...ext\wxWidgets\interface\wx and extracts the information into xml files which are then read by the etg scripts to create the sip and finally the cpp files.
Please note that the header files are from "interface", not from "include". Some are out of sync with the real headers from "include" (e.g. for MediaCtrl).

Your output shows "Checking for ...." and "Attempting to download". This should only happen first time, as the exectuables like doxygen-1.8.8-win32.exe are not from the git repository but from the Phoenix server. Not sure whether a build.py clean should remove these binaries. Maybe I will try later.

Regards,

Dietmar

16

I can confirm that with this setup, "... build.py clean ..." does not remove e.g. the doxygen....exe.
(Neither does a cleanall.)

Regards,

Dietmar

···

Am 01.12.2015 um 18:34 schrieb Dietmar Schwertberger:

- a project directory without spaces in the path
- 32 bit cygwin at c:\cygwin (or rename cygwin64 directory)
- use Windows cmd window instead of cygwin shell

17

I already though of that

But understand that in Windows this is very common specially for users that do not have permission to write in paths outside their user path profile. So changing cygwin path and path of installation is a no go for a big amount of corporate users.

Besides renaming cygwin64 (which is the default name for cygwin 64 bit) would broke several other builds (unless I use a junction point , the Windows NTFS equivalent of a symbolic link, outside the reach of corporate users too).

My intent originally was to just build the stuff, but frankly speaking, the build code is kind of a mess, hard coded paths, even copied again and again all over the code, without ever using a constant (or a single attribution point).

So I changed my mind to at least find all the problematic points and maybe submit some corrections maybe and learn about this build in the process.

Besides the build part do not seem that will change so much between versions (I may be wrong off course), so a patch made with diff would be easy enough to apply in a new version.

Which takes me to my new doubt, Making a git fork is straightforward enough, but my doubt is if Phoenix is a fork of wxWidgets\wxpython, or wxWidgets\wxPython is dead?

I think it attemsts to download because of the clean. I will test it too.

···

On Tuesday, December 1, 2015 at 3:34:34 PM UTC-2, Dietmar Schwertberger wrote:

Why not take the easiest way?

  • a project directory without spaces in the path

  • 32 bit cygwin at c:\cygwin (or rename cygwin64 directory)

  • use Windows cmd window instead of cygwin shell

The problems with spaces in path should of course be fixed, but as long
as there’s no way to update the Github repository with the fixes, it
does not help too much as with the next revision you will need to apply
the changes again…

I’ve just bought a book about git. So hopefully I will find out how to
fork Phoenix including the modifications on Phoenix and wx (building,
ActiveX, MetafileDC, MediaCtrl) such that we have a common work base.
(Or maybe Robin will find the time to merge the pull requests.) For
versions based on wx >3.0.2 some modifications to the build tools are
required as the build process of wx has changed, so for some time we
should stick to a modified 3.0.2.

Yes, Doxygen takes the header files from …ext\wxWidgets\interface\wx
and extracts the information into xml files which are then read by the
etg scripts to create the sip and finally the cpp files.

Please note that the header files are from “interface”, not from
“include”. Some are out of sync with the real headers from “include”
(e.g. for MediaCtrl).

Your output shows “Checking for …” and “Attempting to download”. This
should only happen first time, as the exectuables like
doxygen-1.8.8-win32.exe are not from the git repository but from the
Phoenix server. Not sure whether a build.py clean should remove these
binaries. Maybe I will try later.

Regards,

Dietmar

18

Ok. I was writing the anwser and when I posted it I saw your message. I will try to understant why this is happening too.

···

On Tuesday, December 1, 2015 at 6:03:02 PM UTC-2, Dietmar Schwertberger wrote:

Am 01.12.2015 um 18:34 schrieb Dietmar Schwertberger:

  • a project directory without spaces in the path
  • 32 bit cygwin at c:\cygwin (or rename cygwin64 directory)
  • use Windows cmd window instead of cygwin shell

I can confirm that with this setup, “… build.py clean …” does not
remove e.g. the doxygen…exe.

(Neither does a cleanall.)

Regards,

Dietmar

19

PS. I am not using cygwin shell, just Windows command prompt.

I was almost quitting because numpy for Python 3.5 in Windows 64 bit was not available as well (and I need it too, and it is harder yet to build because of the prerequisites). But the classic unofficial source made it available earlier last month, and I have several uses for the new async IO features. Sometimes I think it is just easier to make all the interface code in C++ as a front end and call the Python parts. But all this is out of the scope of this group.

···

On Tuesday, December 1, 2015 at 6:03:02 PM UTC-2, Dietmar Schwertberger wrote:

Am 01.12.2015 um 18:34 schrieb Dietmar Schwertberger:

  • a project directory without spaces in the path
  • 32 bit cygwin at c:\cygwin (or rename cygwin64 directory)
  • use Windows cmd window instead of cygwin shell

I can confirm that with this setup, “… build.py clean …” does not
remove e.g. the doxygen…exe.

(Neither does a cleanall.)

Regards,

Dietmar

20

But understand that in Windows this is very common specially for users that do not have permission to write in paths outside their user path profile. So changing cygwin path and path of installation is a no go for a big amount of corporate users.

Sure, but with a wheel, they will not need to build it themselves. I appreciate the effort to provide a wheel, as for many people that seems a blocking point. Personally, I can live with building myself. After all, wxPython is a tool for developers, not so much for application users.

Besides renaming cygwin64 (which is the default name for cygwin 64 bit) would broke several other builds (unless I use a junction point , the Windows NTFS equivalent of a symbolic link, outside the reach of corporate users too).

For Phoenix, just the bash shell is required. No matter whether 32 or 64 bit, so 32 bit could be installed in parallel. Anyway, it seems unlikely to me that the corporate user has a cygwin installed but no access to the root directory.
I think that it would be a good idea to get rid of the cygwin stuff on Windows completely. (And also the build.py script should be modified to be Python 2/3 neutral to remove the dependency on 2.7 and the --python= argument.) The functionality of the regen.sh script is probably better included in the build.py. The original intent was probably to always use the latest regen.sh provided by the wx project, but I think there's not too much functionality in the script. Also, it would probably be possible to use the regen.bat script if the build.py defines an alias for the doxygen command (using the "doskey" command). That's something to be tried out (I'm not sure whether such an alias still exists when calling the script). The alternative would be to make a modified copy of the .bat.

My intent originally was to just build the stuff, but frankly speaking, the build code is kind of a mess, hard coded paths, even copied again and again all over the code, without ever using a constant (or a single attribution point).

I think there's a reason for why it's like it is: the purpose of this stuff is to automatically build packages for all supported OS platform and Python versions. If all the binary builds come from a single machine, there's no need to clean up.

So I changed my mind to at least find all the problematic points and maybe submit some corrections maybe and learn about this build in the process.

Besides the build part do not seem that will change so much between versions (I may be wrong off course), so a patch made with diff would be easy enough to apply in a new version.

With a switch to wx >3.0.2 some things will need to be changed in the build system. But yes, merging should be not too hard. On the other hand, modifications also need to be tested on other platforms.

Which takes me to my new doubt, Making a git fork is straightforward enough, but my doubt is if Phoenix is a fork of wxWidgets\wxpython, or wxWidgets\wxPython is dead?

I did not really look, but I would expect it to be a new project with .py files copied over from the old project. There are too many differences to profit from the mechanisms that a fork provides.

Btw.: I just did full builds for Python 3.4, 3.5 and 3.5 64 bit.
For each version I did a
   D:/Python/Python27/python.exe build.py dox etg --nodoc sip build --python=D:/Python/PythonNN/python.exe
   D:/Python/Python27/python.exe build.py bdist_wheel --python=D:/Python/PythonNN/python.exe
   D:/Python/Python27/python.exe build.py clean --python=D:/Python/PythonNN/python.exe

Everything worked fine and I don't have mixed DLLs or .pyds in the wheels. Without the clean steps, the result is a mess...

Regards,

Dietmar

···

Am 01.12.2015 um 21:08 schrieb Airton Granero: