Hmm, I was thinking more along the lines of setting up a travis environment
that would automatically perform a build using cx_Freeze and run the
tests. I would certainly welcome adding additional notes in the
documentation about using cx_Freeze, but I really don't like the idea of
adding binary blobs to a source tree (what is the license for zlib anyway?).

This is certainly interesting to look over, though, as I have zero
experience with cx_Freeze.

On Wed, Aug 20, 2014 at 12:05 PM, Joel B. Mohler notifications@github.com
wrote:

This PR is my fix for #1717
#1717 . I expect I'll
get feedback on the following points so I'm going to state them upfront:

"Why include dependencies' source zips/tarballs?" Simply because there
is no canonical way to do this on Windows and it's not for the faint of
heart. I think its worth it -- there are many Python programmers on Windows
that could contribute but don't want to deal with the details of nmake and
cmake.
2.

"The hack with the symlinks in jbmohler/matplotlib@d6fe8c9
jbmohler@d6fe8c9
is a dirty hack." Yes, I agree. My better suggestion is at #2187
(comment)
#2187 (comment)
. Please vote for that or suggest otherwise.
3.

"Tcl/tk zip files are especially large and you only need the headers."
I think I agree. I did what I did because I think it's nicer to be able
update this merely by plopping in the exact thing downloaded from upstream.
4.

"Now you can't use your own builds of freetype on Windows." That's
true (maybe, kind of) ... many windows devs didn't know how to build it at
all before.

There you have it ... my CYA encrusted PR. :)

You can merge this Pull Request by running

git pull https://github.com/jbmohler/matplotlib win_build

Or view, comment on, or merge it at:

#3388
Commit Summary

• MS Windows dependency inclusion & building
• unpack tcl/tk zip files for headers to build on windows
• prepare a fresh git checkout for doc build on MS windows
• Windows build documentation

File Changes

• M .gitignore
  https://github.com/matplotlib/matplotlib/pull/3388/files#diff-0 (14)
• M INSTALL
  https://github.com/matplotlib/matplotlib/pull/3388/files#diff-1 (47)
• M doc/faq/installing_faq.rst
  https://github.com/matplotlib/matplotlib/pull/3388/files#diff-2 (2)
• M doc/make.py
  https://github.com/matplotlib/matplotlib/pull/3388/files#diff-3 (10)
• M setupext.py
  https://github.com/matplotlib/matplotlib/pull/3388/files#diff-4 (38)
• A setupwin.py
  https://github.com/matplotlib/matplotlib/pull/3388/files#diff-5
  (227)
• A windeps/ft2411.zip
  https://github.com/matplotlib/matplotlib/pull/3388/files#diff-6 (0)
• A windeps/libpng-1.6.7.tar.gz
  https://github.com/matplotlib/matplotlib/pull/3388/files#diff-7 (0)
• A windeps/tcl8513-src.zip
  https://github.com/matplotlib/matplotlib/pull/3388/files#diff-8 (0)
• A windeps/tk8513-src.zip
  https://github.com/matplotlib/matplotlib/pull/3388/files#diff-9 (0)
• A windeps/zlib128.zip
  https://github.com/matplotlib/matplotlib/pull/3388/files#diff-10 (0)

Patch Links:

• https://github.com/matplotlib/matplotlib/pull/3388.patch
• https://github.com/matplotlib/matplotlib/pull/3388.diff

—
Reply to this email directly or view it on GitHub
#3388.

@WeatherGod I'm pretty confused about what cx_Freeze and travis have to do with this PR. As a developer on Windows who wants to tweak (or even just use pre-release code) and build matplotlib, cx_Freeze is entirely outside the scope of my desires. Please clarify?

As for the binary blobs, let me assure you I had to swallow my disgust even in the very act of committing that. I simply believe it is the only surefire way of preventing e-mail threads like http://matplotlib.1069221.n5.nabble.com/Trying-to-build-matplotlib-on-Windows-7-error-related-to-ft2bild-h-td43575.html . The only other likely alternative I can think of is to have setup.py automatically fetches the sources from upstream (and I think that's too fragile).

Yep, I see that travis is telling me to put my distutils.msvc9compiler import behind a platform conditional. I'll get that after I get more feedback here since I'm sure I will.

I am strongly against bundling more code than we absolutely have to.

I think a reasonable compromise is a script that does the windows version of wget (that must exist, right?...) either from the upstream projects or we can put them on SF so we control that.

I am also a bit wary of solving this problem right now. anaconda seems to be picking up momentum and can be used to bundle arbitrary binaries. (Given that they build mpl to package it from windows and they seem to be big fans of eating their own dog food, I would even bet they have already packaged (and might even be shipping) the required dependencies).

Once we start down the path of including arbitrary system-specific dependencies we turn in to a distribution project and will end up with people asking us to ship all of our dependencies (and then their dependencies and then ....).

I think @WeatherGod was mixing this up with #3385.

There has been talk of getting windows-based CI running. It looks like the conda folks use appveyor successfully.

And, yes I see the issues with jumping on the bandwagon of a company, but it makes bunches of pain go away and I have yet to find any new pains because of it.

Including those blobs in git is not acceptable. It seems to me that this Windows installation problem is in the domain of value-added packagers. Anaconda, Canopy, and PythonXY handle this. If you would like to set up a lighter-weight packaging service, including just mpl and its library dependencies, that would be nice. But it has to be done outside the mpl git repo. It's a simple matter of factoring--keeping the core mpl manageable.

It sounds like this is a no-go then. I'll continue on at https://github.com/jbmohler/matplotlib-winbuild as I have need.

I'll let somebody else close this and/or make suggestions about whether https://github.com/jbmohler/matplotlib-winbuild should get an official pointer.

I would be cool with a link. Could your do a pull request against 1.4.x with the text you want?

I would even like to see it in the matplotlib organisation.

Closing this as a PR.

@jbmohler If you are amenable to giving mpl your repo, send an email to the matplotlib-dev list to get feed back.

I still think that we should only keep track of link to get the source not the full blobs.