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

[Airton Granero]

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 "<string>", line 1, in <module>
  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 "<string>", line 1, in <module>
  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.

[Dietmar Schwertberger]

Am 24.11.2015 um 13:12 schrieb Airton Granero:
> I tried to compile wxPython using Python35 and VS2015.

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.


==================================
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:
https://github.com/wxWidgets/wxWidgets/commit/6c20d775c4fd77dfd7fb0e7e679ab8149760413a

==================================
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

[Dietmar Schwertberger]

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

[Airton Granero]

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 <wxdir>\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)

That was corrected changing wscript in this place

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'

....

by adding the line

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

            msvc_version = '14.0'

Compilation gave me some warnings

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

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

#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

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

 

[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/).

[Dietmar Schwertberger]

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

[Airton Granero]

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.

[Dietmar Schwertberger]

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

[Airton Granero]

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 "<stdin>", line 1, in <module>
  File "C:\Python35\lib\site-packages\wx\__init__.py", line 17, in <module>
    from wx.core import *
ImportError: No module named 'wx.core'

[Dietmar Schwertberger]

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

[Airton Granero]

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.

[Dietmar Schwertberger]

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

[Airton Granero]

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 <module>

    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.

[Airton Granero]

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

[Dietmar Schwertberger]

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

[Dietmar Schwertberger]

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

[Airton Granero]

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.

[Airton Granero]

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.

[Airton Granero]

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.

[Dietmar Schwertberger]

Am 01.12.2015 um 21:08 schrieb Airton Granero:
> 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

[Dietmar Schwertberger]

Am 01.12.2015 um 21:38 schrieb Airton Granero:
> 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.

I'm just moving from 2.7 to 3.4.
Asyncio also was the trigger for me to make the switch, while wxPython
held me back for a long time.

But with some minor updates, I don't see wxPython being a reason to
stay with 2 any more for anybody:
- updates to ActiveX, lib.iewin, Metafile/MetafileDC, MediaCtrl (I did
these already, but need some feedback from users)
- updates to the build process (if we throw together our
modifications, we're probably already done with this)
- updates to Grid (the GetValue method) (maybe I will volunteer for
this, but not before end of the year)
- updates to the documentation (I will not volunteer)
- updates to the demos (I could imagine we'll find a volunteer)
- testers for the different platforms
After that some work on build.py is required for the changed wx build
process (build-wxwidgets.py is no longer maintained).

The next step from my side is to read my Git book. After that, we can
coordinate on the -dev mailing list...


Regards,

Dietmar

[Airton Granero]

I just agree with all.

• making the build Python 2/3 neutral would be great, I took some time to realize the --python parameter in the beginning,
  
• getting rid of cygwin stuff is the way to go, the less dependencies the better,
  
• I rather use Python scripts that shell scripts, they are platform independent, more expressive to read and easier to debug

[Airton Granero]

I've just made it.
I have followed you suggestion and put everything on a directory under root.
I installed the wheel and the import worked. I will do more tests later.
I will organize the changes so later I can contribute to the build.

Thanks.