[CMake] CMake 2.6 - Runtime Error on OS X (10.4.11 Intel)

[Mike Jackson]

Bug 0006286 submitted.. finally..


On Jan 14, 2008 12:33 PM, Mike Jackson <imikejackson at gmail.com> wrote:
>
> On Jan 14, 2008, at 12:20 PM, Bill Hoffman wrote:
>
> > Mike Jackson wrote:
> >> I just built the latest CVS head of CMake and tried running on OS
> >> X (10.4.11 Intel) and noticed a few things.
> >> 1: CMake Error: CMake executable cannot be found at /Users/Shared/
> >> Toolkits/CMake-ICC/bin/QtDialog.app/Contents/MacOS/cmake
> >> Probably just a path issue between the .app bundle and the
> >> internal call to cmake.
> > This needs to be fixed, the QtDialog is not very tested right now,
> > please create a bug entry for this.
>
> OK.
> >
> >> 2: ADD_LIBRARY for library MXADataModel is used with the SHARED
> >> option, but the target platform supports only STATIC libraries.
> >> Building it STATIC instead. This may lead to problems.
> >
> > What is MXADataModel?
>
> It is the name of my project. Sorry about not explaining that.
>
> >> This seems to work fine with CMake 2.4.7 on the same project. I
> >> compiled CMake 2.6 CVS Head with both GCC (Xcode 2.5 tools) and
> >> ICC/ICPC (version 9.x) and saw this problem.
> >
> > What did 2.4.7 do?
>
> Well, since there is no GUI to test with 2.4.7, the command line
> cmake did the correct thing.
>
> >
> >> Not sure if the two are related or not.
> > Don't think so.
>
> Actually, they are. If I copy cmake into the QtDialog.app/Contents/
> MacOS then everything works correctly.
>
> I don't really know how to do a "patch" but this is what I have
> found. The QtDialog correctly sets the absolute path to the cmake
> executable (Yes, Clinton, I did change my code slightly) BUT the
> problem is in cmake.cxx in the AddPaths() method:
>
> int cmake::AddCMakePaths()
> {
>    // Find the cmake executable
>    std::cout << "cmake::AddCMakePaths() this->CMakeCommand: " << this-
>  >CMakeCommand  << std::endl;
>    std::string cMakeSelf = cmSystemTools::GetExecutableDirectory();
>    cMakeSelf += "/cmake";
>    cMakeSelf += cmSystemTools::GetExecutableExtension();
>    std::cout << "cmake::AddCMakePaths() this->cMakeSelf: " <<
> cMakeSelf << std::endl;
>
> in this method the assumption I guess is that this->CMakeCommand has
> NOT been set so the algorithm recalculates it. Normally this probably
> is not a problem, with OS X app bundles this is going to be WRONG. By
> using the above added lines to look at some values I get the
> following output:
>
> cmake::AddCMakePaths() this->CMakeCommand: /Users/Shared/Toolkits/
> CMake-ICC/bin/QtDialog.app/Contents/bin/cmake
> cmake::AddCMakePaths() this->cMakeSelf: /Users/Shared/Toolkits/CMake-
> ICC/bin/QtDialog.app/Contents/MacOS/cmake
>
> You can see that the values are different. I am not sure how the
> internals of cmake work BUT it would seem at first glance that a test
> is needed to see if this->CMakeCommand is actually set, that the file
> does exist and use the value for cMakeSelf if it DOES exist.. or
> something to that effect.
>
>
> --
> Mike Jackson   Senior Research Engineer
> Innovative Management & Technology Services
> OS X Build Specialist
>
>
>



-- 
Mike Jackson
imikejackson _at_ gee-mail dot com