Building the client_handler requires Python in a specific location

[GoogleCodeExporter]

This is a minor issue and might only affect people which run multiple python 
installations / python installed in the default directory on windows.

What steps will reproduce the problem?
1. Install python into its default location
2. Try compiling the client_handler module using Visual Studio 2008

What is the expected output? What do you see instead?
Expected: client_handler builds without problems.
Actual output: Compiler cannot find python include files.

What version of the product are you using? On what operating system?
Windows 7 32-bit, Python 2.7.2, cefpython revision 82835379a6b2a359

Please provide any additional information below.
Attached is a patch allowing users to configure the location of their python 
include files using the PYTHON_INCLUDE_PATH environment variable.

Original issue reported on code.google.com by t.daehl...@googlemail.com on 14 Mar 2013 at 11:30

Attachments:

• 0001-Remove-hard-coded-path-from-CEF3-client-handler.patch

[GoogleCodeExporter]

In revision 07aac6627c3d I've changed python path in visual c project
files to "C:\Python27" and "C:\Python32", these are the defaults when
installing ActivePython, would that work for you? Or is the PYTHON_INCLUDE_PATH 
required? When I'm changing python runtime I edit the PATH variable,
but this change would require me to make an additional step of changing the
PYTHON_INCLUDE_PATH, right? Or is it possible to use PYTHON_INCLUDE_PATH
variable in PATH?

Original comment by czarek.t...@gmail.com on 14 Mar 2013 at 1:55

[GoogleCodeExporter]

Your paths would indeed default to the default python installation directories, 
which is probably going to work out of the box for most people.
The reason I opted for the environment variable is that I am running different 
python installations in parallel (for example a vanilla Python 2.7.3, a 
stackless version of it and a Python 2.7.2 installation). This way I can easily 
choose the version to use. Yes this would mean that I would have to change the 
environment variable everytime, but I don't have to modify the actual 
buildscripts in this scenario and thus can simply compile from the same source. 
Imagine having a seperate console window open for each python installation with 
the appropriate environment specified in there.

Original comment by t.daehl...@googlemail.com on 14 Mar 2013 at 3:17

[GoogleCodeExporter]

Or we can have both, the hardcoded "C:\Python27" and additionally 
$(PYTHON_INCLUDE_PATH). If the "C:\Python27" doesn't exist, it shouldn't
be a problem when compiling as long as you have PYTHON_INCLUDE_PATH set, 
would that work for you?

Original comment by czarek.t...@gmail.com on 14 Mar 2013 at 4:10

• Changed state: Accepted

[GoogleCodeExporter]

As long as the variable is checked before it falls back to the default 
directory that should work nicely.

Original comment by t.daehl...@googlemail.com on 14 Mar 2013 at 4:19

[GoogleCodeExporter]

It will always use the default directory, this will be a problem if
both PYTHON_INCLUDE_PATH and the default directory exist, but this
could be solved by adding $(PYTHON_INCLUDE_PATH) before C:\Python27\include
in AdditionalIncludeDirectories, so that it is:

    AdditionalIncludeDirectories="../;$(PYTHON_INCLUDE_PATH);C:\Python27\include"

This way if you have set PYTHON_INCLUDE_PATH it won't include a file in the
hardcoded directory if the file is found in PYTHON_INCLUDE_PATH (I'm assuming
that the precedence of the include directories starts on the left).

Original comment by czarek.t...@gmail.com on 14 Mar 2013 at 4:31

[GoogleCodeExporter]

I've tested and PYTHON_INCLUDE_PATH takes precedence, so it works fine.
Commited in revision 39806ea05d16.

Original comment by czarek.t...@gmail.com on 14 Mar 2013 at 4:43

• Changed state: Fixed