MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0013312CMakeCMakepublic2012-06-18 08:382013-01-09 10:57
ReporterSamuel John 
Assigned ToDavid Cole 
PriorityhighSeverityminorReproducibilityalways
StatusclosedResolutionno change required 
PlatformdarwinOSMac OSOS Version10.7.4
Product VersionCMake 2.8.8 
Target VersionFixed in VersionCMake 2.8.10 
Summary0013312: Finding the tk.framework inside of Xcode 4.3 fails to find the private headers
DescriptionThe Framework inside of Xcode is located at /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/Tk.framework.

I have no problems to set CMAKE_FRAMEWORK_PATH such that Tk.framework is found.
But the PrivateHeaders are actually located at
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/Tk.framework/Headers/tk-private

From this code in the FindTCL.cmake I see that the "tk-private" postfix is not added but "/PrivateHeaders" which is not there.


```
SET(TK_FRAMEWORK_INCLUDES)
IF(Tk_FRAMEWORKS)
  IF(NOT TK_INCLUDE_PATH)
    FOREACH(dir ${Tk_FRAMEWORKS})
      SET(TK_FRAMEWORK_INCLUDES ${TK_FRAMEWORK_INCLUDES}
        ${dir}/Headers ${dir}/PrivateHeaders)
    ENDFOREACH(dir)
  ENDIF(NOT TK_INCLUDE_PATH)
ENDIF(Tk_FRAMEWORKS)
```

Steps To ReproduceI stumbled upon this trying to build vtk on OS X.
Additional Information
The homebrew vtk formula
https://github.com/mxcl/homebrew/pull/12807 [^]
TagsNo tags attached.
Relationships
related to 0000423closed Brad King The Python framework is not always found on OSX 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2012-06-18 08:38Samuel JohnNew Issue
2012-06-18 08:55Brad KingRelationship addedrelated to 0000423
2012-06-18 08:58Brad KingNote Added: 0029717
2012-06-18 08:58Brad KingNote Added: 0029718
2012-06-18 09:13Samuel JohnNote Added: 0029719
2012-06-18 10:48Samuel JohnNote Added: 0029720
2012-06-18 10:54Brad KingNote Added: 0029721
2012-06-18 10:58Samuel JohnNote Added: 0029722
2012-08-11 21:42David ColeStatusnew => backlog
2012-08-11 21:42David ColeNote Added: 0030444
2012-08-12 06:06Samuel JohnNote Added: 0030456
2012-08-12 06:06Samuel JohnNote Added: 0030457
2012-08-12 07:50David ColeAssigned To => David Cole
2012-08-12 07:50David ColeStatusbacklog => assigned
2012-08-12 07:51David ColeNote Added: 0030459
2012-08-12 07:51David ColeStatusassigned => resolved
2012-08-12 07:51David ColeFixed in Version => CMake 2.8.10
2012-08-12 07:51David ColeResolutionopen => no change required
2013-01-09 10:57Robert MaynardNote Added: 0032047
2013-01-09 10:57Robert MaynardStatusresolved => closed

Notes
(0029717)
Brad King   
2012-06-18 08:58   
The "PrivateHeaders" name was originally added here:

 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1d0569e7 [^]

and put in its current form here:

 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=13e9428d#patch3 [^]

I'm sure the installed name may have changed since then.
(0029718)
Brad King   
2012-06-18 08:58   
Is there a specific patch you have in mind?
(0029719)
Samuel John   
2012-06-18 09:13   
I am currently testing this..
151c151
< ${dir}/Headers ${dir}/PrivateHeaders ${dir}/Headers/tk-private)
---
> ${dir}/Headers ${dir}/PrivateHeaders)

I'll attach a the patch file if it solves my problems!
(0029720)
Samuel John   
2012-06-18 10:48   
My patch did not help.
Perhaps this issuse is more on the VTK side than on the cmake side?
I assumed TK_INTERNAL_PATH is used to find the PrivateHeaders.

When I force TK_INTERNAL_PATH to point to the PrivateHeaders it compiles fine.

I found that VTK searches the TK_INTERNAL_PATH and finds the include files in the build/Utilities/TclTK/internal dir which clashes with the definitions provided by Apples TclTK located inside of Xcode.

# - TK_INTERNAL_PATH was removed.
# => this ended up being only a Win32 variable, and there is a lot of
# confusion regarding the location of this file in an installed Tcl/Tk
# tree anyway (see 8.5 for example). If you need the internal path at
# this point it is safer you ask directly where the *source* tree is
# and dig from there.

Should VTK not be using the TK_INTERNAL_PATH at all?
(0029721)
Brad King   
2012-06-18 10:54   
Re 0013312:0029720: I suggest posting on a VTK mailing list to get that worked out first.
(0029722)
Samuel John   
2012-06-18 10:58   
I'll come back if I resolved the issue (probably tomorrow).
Thanks for your quick response.
I'd like to leave this open until then in order to sort it out.
(0030444)
David Cole   
2012-08-11 21:42   
Sending old, never assigned issues to the backlog.

(The age of the bug, plus the fact that it's never been assigned to anyone means that nobody is actively working on it...)

If an issue you care about is sent to the backlog when you feel it should have been addressed in a different manner, please bring it up on the CMake mailing list for discussion. Sign up for the mailing list here, if you're not already on it: http://www.cmake.org/mailman/listinfo/cmake [^]

It's easy to re-activate a bug here if you can find a CMake developer who has the bandwidth to take it on, and ferry a fix through to our 'next' branch for dashboard testing.
(0030456)
Samuel John   
2012-08-12 06:06   
I've come to the conclusion that building vtk works if we point to the TK headers explicitly:

     # We are facing an Xcode-only installation, and we have to keep
     # vtk from using its internal Tk headers (that differ from OSX's).
     -DTK_INCLUDE_PATH:PATH=$(SDKROOT)/System/Library/Frameworks/Tk.framework/Headers
     -DTK_INTERNAL_PATH:PATH=$(SDKROOT)/System/Library/Frameworks/Tk.framework/Headers/tk-private

This needs to be set on OS X 10.8 with Xcode (without the Command Line Tools for Xcode).
So probably cmake itself is fine!
Thanks!
(0030457)
Samuel John   
2012-08-12 06:06   
Ticket can be closed.
(0030459)
David Cole   
2012-08-12 07:51   
Resolving at the request of the reporter
(0032047)
Robert Maynard   
2013-01-09 10:57   
Closing resolved issues that have not been updated in more than 4 months.