Bug 132023 - [Win] Support Python 2.7 in Cygwin
Summary: [Win] Support Python 2.7 in Cygwin
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Brent Fulgham
URL:
Keywords: InRadar
Depends on:
Blocks: 132826
  Show dependency treegraph
 
Reported: 2014-04-22 13:52 PDT by Brent Fulgham
Modified: 2014-05-12 10:25 PDT (History)
7 users (show)

See Also:


Attachments
Patch (26.37 KB, patch)
2014-04-22 14:05 PDT, Brent Fulgham
msaboff: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Brent Fulgham 2014-04-22 13:52:34 PDT
We have been blocked from moving from Python 2.6 to Python 2.7 for some time due to the following build error:

"Invalid Python installation: unable to open ‘/cygdrive/c/Cygwin/include/python2.7/pyconfig.h”

I tracked down the cause of the issue:

1. We explicitly add the path to the Cygwin 'bin' directory in various of our build scripts and Makefile invocations.
2. Cygwin therefore often believes that Python lives at a location like "/cygdrive/c/Cygwin/bin/python.exe".
3. Python (as of 2.7 and newer) started checking for its configuration header in "../include/python2.7/pyconfig.h".
4. Cygwin has a quirk where many of its binaries exist in "/bin" and "/usr/bin" simultaneously (e.g. symlnked).
5. Pathing causes "/bin/python" to be found in preference to "/usr/bin/python"

Because of the issues I list above, Python expected to find its configuration file in "/include/python2.7/pyconfig.h".When it could not do so, it would exit with an error.

If we always invoke Python using the explicit path "/usr/bin/python", then the relative directory paths work properly and Python is happy.

Because Cygwin's UNIX environment always places Python at "/bin/python" and "/usr/bin/python", regardless of where the user actually installs the Cygwin framework, we can rely on these paths in our scripts.

To resolve this, I have done the following:

1. The scripts that invoke Python (and Perl) in Windows-specific build steps are simply hard coded as "/usr/bin/python" (and /usr/bin/perl).
2. All other scripts use a PYTHON (and PERL) variable, which is conditionally set to "/usr/bin/python" for Windows builds, and just "python" for all other builds.

With these changes, we can successfully build with Python 2.7 (and newer).

These changes have the added benefit of ensuring we invoke the Cygwin python in our builds, rather than the first Python found in the path. This has been a problem for some users who also have ActiveState or other Python builds installed on their systems. I'm sure the same is true for Perl installations.
Comment 1 Brent Fulgham 2014-04-22 14:05:33 PDT
Created attachment 229911 [details]
Patch
Comment 2 Michael Saboff 2014-04-22 14:09:55 PDT
Comment on attachment 229911 [details]
Patch

r=me
Comment 3 Brent Fulgham 2014-04-22 14:59:10 PDT
Committed r167685: <http://trac.webkit.org/changeset/167685>
Comment 4 Joseph Pecoraro 2014-04-23 13:03:46 PDT
Comment on attachment 229911 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=229911&action=review

> Source/JavaScriptCore/DerivedSources.make:69
> +# Windows has specific needs for specifying the path to its interpreters

It would be awesome to include those needs (basically a smaller snippet of the bugzilla bug comment) here or in the ChangeLog. That way, when someone reads this and wants to know why, they don't have to make the extra jump to bugzilla to find out why.
Comment 5 Radar WebKit Bug Importer 2014-04-23 23:09:36 PDT
<rdar://problem/16709226>