Yeah binaries solve one problem, but not the problem of why the builds
I do fail. It's not a show-stopper for our software development, but
it is the sort of thing that should Just Work, and builds of current
GIT repository worked fine a few weeks ago, and 2.8.1 built as well.
Oh well!
On Tue, Ma
On 5/11/2010 4:47 PM, kent williams wrote:
I tried copying it to the suggested place, but it still didn't work.
My solution, since I'm not a CMake developer, was to go back to using
xterm -e ccmake instead of the Qt dialog.
What about the nightly binaries created at Kitware:
http://www.cmake.
I tried copying it to the suggested place, but it still didn't work.
My solution, since I'm not a CMake developer, was to go back to using
xterm -e ccmake instead of the Qt dialog.
On Tue, May 11, 2010 at 1:23 PM, Clinton Stimpson wrote:
>
> Just a thought: does it change anything if you make a s
Just a thought: does it change anything if you make a softlink
Versions/Current/Resources -> Resources in QtGui.framework? The message says
QtGui.framework/Versions/Current/Resources/ but when I last tried it, it was
actually looking in QtGui.framework/Resources. They may have changed/fixed
OS X 10.5.8, Qt-4.6.2, g++-4.2 gcc-4.2
../cmake/bootstrap --prefix=/scratch/kent/opt --qt-gui
--qt-qmake=/opt/Qt-4.6.2/bin/qmake
make
make install
/scratch/kent/opt/CMake\ 2.9-20100511.app/Contents/MacOS/CMake\ 2.9-20100511
Qt internal error: qt_menu.nib could not be loaded. The .nib file
should
