Skip to content
This repository has been archived by the owner on Jul 4, 2023. It is now read-only.

CMake Find(python) - wrong includes #10393

Closed
2bits opened this issue Feb 22, 2012 · 12 comments
Closed

CMake Find(python) - wrong includes #10393

2bits opened this issue Feb 22, 2012 · 12 comments

Comments

@2bits
Copy link
Contributor

2bits commented Feb 22, 2012

I'm writing a few new formula. I have Homebrew's python-2.7.2 installed
and in my PATH and PYTHONPATH before the system python.

CMake finds the right libs and binary, but the wrong includes directory:

-- Found PythonLibs: /usr/local/lib/libpython2.7.dylib (Required is at least version "2.6")
-- Boost version: 1.48.0
-- Found the following Boost libraries:
--   python
-- Python found TRUE 
-- Python include dirs /System/Library/Frameworks/Python.framework/Headers
-- Python libraries    /usr/local/lib/libpython2.7.dylib
-- Create version.h from version.h.in
-- Found PythonInterp: /usr/local/bin/python (found version "2.7.2")


$ echo $PATH
/usr/local/bin:/usr/local/sbin:/usr/local/share/python:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11/bin

$ echo $PYTHONPATH
/usr/local/lib/python2.7/site-packages:

Is this expected behavior? I know I can pass it something like this if I want to, but still:

args << "-DPYTHON_INCLUDE_DIR=#{py27.include}" if py27.installed?
@adamv
Copy link
Contributor

adamv commented Feb 22, 2012

This is obviously wrong but I don't know how to tell CMake to unbreak itself.

@Sharpie
Copy link
Contributor

Sharpie commented Feb 22, 2012

Upstream issue.

Basically, CMake clings to Frameworks like a drowning sailor on OSX. See the VTK formula for one way of dealing with this.

@2bits
Copy link
Contributor Author

2bits commented Feb 22, 2012

Classic. I want that on a T-shirt.

@2bits
Copy link
Contributor Author

2bits commented Feb 22, 2012

checking to see if it was boost bottle issue... building from source with homebrew python... Not a boost issue. It is still using Frameworks.

@Sharpie
Copy link
Contributor

Sharpie commented Feb 22, 2012

I'm pretty sure this has nothing to do with Boost. CMake finds the binaries and libs using the PATH but seems to use a different method for finding includes that is overly attracted to Framework folders.

Both VTK and OpenCV have a block of hacks that deal with this.

@2bits
Copy link
Contributor Author

2bits commented Feb 23, 2012

If I wanted to take this upstream, how could I be sure it's not my software? @Sharpie could you craft me a hello world CMakeLists that looks for FindPythonInterp and FindPythonLibs please? That'd be epic. That Qt one you did was genius.

Because this issue would be common to anyone who rolls their own python, is it obvious Kitware is not concerned because PYTHON_INCLUDE_DIR is easily overriden?

@2bits
Copy link
Contributor Author

2bits commented Feb 24, 2012

I can always override this I figure. Moving on.

@2bits 2bits closed this as completed Feb 24, 2012
@2bits 2bits reopened this Feb 25, 2012
@2bits
Copy link
Contributor Author

2bits commented Feb 25, 2012

@adamv @Sharpie I just found that if I build python as a Framework, then I don't get any of these problems, and I don't have to patch the cmake_install.cmake to include the correct site-packages folder.

@camillol
Copy link
Contributor

Why isn't Python built as a framework by default, I wonder?

@2bits
Copy link
Contributor Author

2bits commented Feb 25, 2012

I'm not convinced I've got this nailed yet. CMake doesn't always find the correct python includes, even when I built python as a Framework. I'll have to look through about 5 formula that try to locate python in order to determine what they are doing in their find modules. As I mentioned in an earlier post, FindPythonInterp.cmake and FindPythonLibs.cmake in the Cellar are the only ones I found to reference.

@2bits
Copy link
Contributor Author

2bits commented Feb 25, 2012

I found this bug: Formula.factory('python').include returns a non-existent path when python is brewed as a Framework.

@2bits
Copy link
Contributor Author

2bits commented Feb 26, 2012

If I can make a reproducible testcase of CMake and python headers, I will repopen this. Otherwise it can be overriden and is really upstream like sharpie said.

@2bits 2bits closed this as completed Feb 26, 2012
gadomski added a commit to gadomski/homebrew that referenced this issue Feb 28, 2014
When building --HEAD and --with-python, CMake gets confused by multiple
python installations, e.g. when both Homebrew and system Pythons exist
(see Homebrew#10393 for one example).
This patch lifts some hacks from
https://github.com/Homebrew/homebrew/blob/51d054c/Library/Formula/opencv.rb
to point CMake to the Homebrew Python only, if one exists.

N.B. brew test ledger seems to be  broken when installed --HEAD for
unrelated reasons.
gadomski added a commit to gadomski/homebrew that referenced this issue Mar 4, 2014
When building --HEAD and --with-python, CMake gets confused by multiple
python installations, e.g. when both Homebrew and system Pythons exist
(see Homebrew#10393 for one example).
This patch lifts some hacks from
https://github.com/Homebrew/homebrew/blob/51d054c/Library/Formula/opencv.rb
to point CMake to the Homebrew Python only, if one exists and is
installed.

N.B. brew test ledger seems to be  broken when installed --HEAD for
unrelated reasons.
MikeMcQuaid pushed a commit that referenced this issue Mar 5, 2014
When building --HEAD and --with-python, CMake gets confused by multiple
python installations, e.g. when both Homebrew and system Pythons exist
(see #10393 for one example).
This patch lifts some hacks from
https://github.com/Homebrew/homebrew/blob/51d054c/Library/Formula/opencv.rb
to point CMake to the Homebrew Python only, if one exists and is
installed.

N.B. brew test ledger seems to be  broken when installed --HEAD for
unrelated reasons.

Closes #27095.

Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
ehershey pushed a commit to ehershey/homebrew that referenced this issue Apr 4, 2014
When building --HEAD and --with-python, CMake gets confused by multiple
python installations, e.g. when both Homebrew and system Pythons exist
(see Homebrew#10393 for one example).
This patch lifts some hacks from
https://github.com/Homebrew/homebrew/blob/51d054c/Library/Formula/opencv.rb
to point CMake to the Homebrew Python only, if one exists and is
installed.

N.B. brew test ledger seems to be  broken when installed --HEAD for
unrelated reasons.

Closes Homebrew#27095.

Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
@Homebrew Homebrew locked and limited conversation to collaborators Feb 16, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants