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