Re: [CMake] BundleUtilities with MinGW under Windows
And what error messages are you getting? Clint - Original Message - > Sorry for the missing information. > I use CMake 2.8.4 and have also Visual Studio 2008 installed. > > > Best Regards > > Am 19.05.2011 um 05:52 schrieb "Clinton Stimpson" < > clin...@elemtech.com >: > > > > > > > > > What version of cmake? I don't think that QtTest example worked until > CMake 2.8.3. > > > And you have dumpbin available on Windows from a Visual Studio > installation? > It might be nice to add support for mingw's objdump tool to find > dependent dlls. > > > Clint > > > On May 14, 2011, at 7:48 AM, NoRulez wrote: > > > > > > Hi @all, > > does anyone get BundleUtilities working on Windows and could give me > help? > I tried BundleUtilities under Windows, but the Qt dll’s (such as > QtGui4.dll, …) and the MinGW dll’s (mingwm10.dll and > libgcc_s_dw2-1.dll) are not packaged. > > I also tried the following, but same problem here: > http://www.vtk.org/Wiki/images/2/25/QtTest-Package-Example.zip > > The following example does also not work on linux > > Much thanks in advance > > Best Regards > NoRulez > ___ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake > > > > ___ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How pass a -spec parameter to FindQt4.cmake?
- Original Message - > Hi Clint and thanks for your advices (sorry about the delayed > answer), > > On Tue, Jul 19, 2011 at 1:33 AM, clin...@elemtech.com > wrote: > > When cross compiling, only some the qmake queries are actually > > used. > > > > Finding the rest just works if subdirs in the Qt installation > > weren't given > > different values when running Qt's configure script (e.g. > > --libdir=mylib or > > --libdir=lib/qt4). > > > > So, the root of the Qt installation needs to be given in the > > toolchain file. > > Is /opt/env/lenny-ppc/usr/lib/qt4 the root of the installation, or > > the > > location of the libraries? > > > In either case, it won't be searched unless you put that in your > >toolchain > > file. The standard cross compile find variables are the global > > variables you > > can setto help find Qt. > > I included /opt/env/lenny-ppc/usr/share/qt4 (which I belive to be the > root of > the Qt installation) in CMAKE_FIND_ROOT_PATH but the Qt libraries > still wasn't > detected. > > > Then, if you need to help it some more, you may set the path to the > > QtCore > > library manually, or other variables manually. > > Managed to compile and link when I added the following snippet to the > toolchain file: > > set(QT_HEADERS_DIR /opt/env/lenny-ppc/usr/lib) > set(QT_LIBRARY_DIR /opt/env/lenny-ppc/usr/include/qt4) > > set(QT_QTCORE_LIBRARY /opt/env/lenny-ppc/usr/lib/libQtCore.so) > set(QT_QTCORE_LIBRARY_RELEASE > /opt/env/lenny-ppc/usr/lib/libQtCore.so) > set(QT_QTCORE_INCLUDE_DIR /opt/env/lenny-ppc/usr/include/qt4) > > set(QT_QTDBUS_LIBRARY /opt/env/lenny-ppc/usr/lib/libQtDBus.so) > set(QT_QTDBUS_LIBRARY_RELEASE > /opt/env/lenny-ppc/usr/lib/libQtDBus.so) > set(QT_QTDBUS_INCLUDE_DIR /opt/env/lenny-ppc/usr/include/qt4) > > set(QT_QTXML_LIBRARY /opt/env/lenny-ppc/usr/lib/libQtXml.so) > set(QT_QTXML_LIBRARY_RELEASE > /opt/env/lenny-ppc/usr/lib/libQtXml.so) > set(QT_QTXML_INCLUDE_DIR /opt/env/lenny-ppc/usr/include/qt4) > > Would have been nice if I didn't have to set those paths explicitely. > Will continue the digging. Does it work if you only specify just this: set(QT_HEADERS_DIR /opt/env/lenny-ppc/usr/include/qt4) set(QT_QTCORE_LIBRARY_RELEASE /opt/env/lenny-ppc/usr/lib/libQtCore.so) And I would have thought it can find QtCore if /opt/env/lenny-ppc/usr was given as a find root. No? Clint ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Not matching versions of MSVC Runtime Libraries in Manifest
Here's my (not so complete) understanding... Public assemblies are searched before private ones. http://msdn.microsoft.com/en-us/library/aa374224(v=vs.85).aspx So, on your machine, you have the required CRT libraires in the winsxs folder. You also have a redirection that says to use a newer CRT library if a particular older one is requested. If another machine that you copy this software to doesn't have a shared CRT that will work, it falls back to the one you copied next to your application. So its a way to get updates and bug fixes to the CRT via windows updates, but still allow your application to work on older machines without the newer dlls, by using the ones you provided. Clint - Original Message - > Yes, I think part of the issue is what is mentioned and I do have > plugins (Qt based) and have taken the steps he lays out. But I am > still curious as to why Dependency Walker says it is using one > version of the runtime libraries when the Manifest (both external > and embedded) says to use another. I am probably just missing > something basic in all of this. > > ___ > Mike Jackson www.bluequartz.net > Principal Software Engineer mike.jack...@bluequartz.net > BlueQuartz Software Dayton, Ohio > > On Aug 9, 2011, at 3:07 PM, Michael Wild wrote: > > > On Tue 09 Aug 2011 06:48:34 PM CEST, Michael Jackson wrote: > >> Not sure if this is a CMake issue or not but I'll give it a shot. > >> I am packaging up my application using CPack (zip) and all seems > >> fine. I get the MSVC runtime libraries copied and the manifest > >> file created and all seems to run just fine. If I use Dependency > >> Walker to look at exactly _which_ C/C++ runtime DLLs are being > >> loaded it seems to indicate a newer version than what the > >> manifest is saying. My Application seems to be requesting version > >> 9.0.21022.8 in its manifest and in the executable itself > >> (Embedded Manifest) but Dependency Walker says it is really > >> loading the 9.0.30729.490 version from the winsxs folder. I am > >> still really new to this with Visual Studio so I am not sure if I > >> am doing something incorrect when writing the CPack code, > >> something in Visual Studio, how I compiled all the dependent > >> libraries or what but any help or pushes in a better direction > >> would be greatly appreciated. > >> > >> System: Windows 7 X64 Pro. Visual Studio 2008. Compiling > >> everything as 64 bit. The actual executables can be downloaded > >> from http://dream3d.bluequartz.net. > >> > >> Thanks in advance. > > > > > > Not sure, but could it be the issue mentioned in Bills blog? > > > > http://www.kitware.com/blog/home/post/4 > > > > Michael > > ___ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > > Follow this link to subscribe/unsubscribe: > > http://www.cmake.org/mailman/listinfo/cmake > > ___ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake > ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Font Size of CMake-GUI
On Monday 08 September 2008 9:12:29 am Maik Beckmann wrote: > Am Montag 08 September 2008 schrieb Allen Barnett: > > Hi: I'm running CMake 2.6.1 on my Fedora 7 laptop. I guess I'm getting > > old because the default font size of the GUI is too small for me to > > read. In particular, the output window font is so small that the > > characters are not completely rendered. Is there a way to control the > > font size of the GUI? > > Thanks, > > Allen > > qtconfig(4?) is there to set the look of qt apps. That's usually a tool for the developers. If one doesn't touch it, the Qt applications follow the desktop settings. Clint ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake link against Qt4's OpenGL
It should simply be:
PROJECT ( COMBINED )
FIND_PACKAGE (Qt4 REQUIRED)
SET(QT_USE_QTOPENGL TRUE)
INCLUDE( ${QT_USE_FILE} )
ADD_EXECUTABLE(exe main.cpp glwidget.cpp window.cpp)
TARGET_LINK_LIBRARIES(exe ${QT_LIBRARIES})
Clint
On Friday 26 September 2008 1:02:43 pm Linge Bai wrote:
> Hi everybody,
>
> I have a project developed by Qt4's OpenGL, for example plenty of usage of
> QGLWidget class. I want to use cmake to compile this project, instead of
> using qmake, because I need to combine another project to it. I can only
> link against Qt4 and OpenGL seperately. But I cannot link against Qt4's
> OpenGL by simply setting SET(QT_USE_QTOPENGL TRUE),
> ${QT_QTOPENGL_INCLUDE_DIR} or ${QT_QTOPENGL_LIBRARY}. I have no idea about
> what else I need to add to my CMakeList.txt file:
>
> PROJECT ( COMBINED )
>
> FIND_PACKAGE (Qt4 REQUIRED)
> FIND_PACKAGE (OPENGL REQUIRED)
> SET(QT_USE_QTMAIN TRUE)
> SET(QT_USE_QTCORE TRUE)
> SET(QT_USE_QTGUI TRUE)
> SET(QT_USE_QTOPENGL TRUE)
> INCLUDE( ${QT_USE_FILE} )
>
> INCLUDE_DIRECTORIES(
> ${QT_INCLUDES}
> ${QT_INCLUDE_DIR}
> ${QT_QT_INCLUDE_DIR}
> ${QT_QTCORE_INCLUDE_DIR}
> ${QT_QTGUI_INCLUDE_DIR}
> ${QT_QTOPENGL_INCLUDE_DIR}
> )
>
> LINK_DIRECTORIES(
> ${QT_LIBRARIES}
> ${QT_LIBRARY_DIR}
> ${QT_QTOPENGL_LIBRARY}
> ${QT_QTGUI_LIBRARY}
> ${QT_QTCORE_LIBRARY}
> ${QT_MAIN_LIBRARY}
> )
>
> ADD_EXECUTABLE(exe main.cpp glwidget.cpp window.cpp)
> TARGET_LINK_LIBRARIES(exe ${QT_LIBRARIES})
>
> Could anyone please post a simple example to do this? Or could anyone
> please give me some suggestions? Any help would be greatly appreciated.
>
> thanks,
> Linge
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake link against Qt4's OpenGL
Then you must have a static build of Qt?
If you use CMake 2.6.0 or greater, it should work with a static Qt.
Clint
On Friday 26 September 2008 1:22:54 pm Linge Bai wrote:
> I still have the same problems:
> [15:20:04] ~/Desktop/myQt/hellogl$
> cmake .
> -- Found Qt-Version 4.4.2
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /Users/lb353/Desktop/myQt/hellogl
> [15:20:08] ~/Desktop/myQt/hellogl$
> make
> Scanning dependencies of target exe
> [ 33%] Building CXX object CMakeFiles/exe.dir/main.o
> [ 66%] Building CXX object CMakeFiles/exe.dir/glwidget.o
> [100%] Building CXX object CMakeFiles/exe.dir/window.o
> Linking CXX executable exe
> Undefined symbols:
> "_glEnable", referenced from:
> GLWidget::initializeGL() in glwidget.o
> GLWidget::initializeGL() in glwidget.o
> "_glEnd", referenced from:
> GLWidget::makeObject() in glwidget.o
> "_glGenLists", referenced from:
> GLWidget::makeObject() in glwidget.o
> "_glMatrixMode", referenced from:
> GLWidget::resizeGL(int, int)in glwidget.o
> GLWidget::resizeGL(int, int)in glwidget.o
> "_glEndList", referenced from:
> GLWidget::makeObject() in glwidget.o
> "GLWidget::zRotationChanged(int)", referenced from:
> GLWidget::setZRotation(int) in glwidget.o
> "_glRotated", referenced from:
> GLWidget::paintGL() in glwidget.o
> GLWidget::paintGL() in glwidget.o
> GLWidget::paintGL() in glwidget.o
> "_glCallList", referenced from:
> GLWidget::paintGL() in glwidget.o
> "GLWidget::xRotationChanged(int)", referenced from:
> GLWidget::setXRotation(int) in glwidget.o
> "_glViewport", referenced from:
> GLWidget::resizeGL(int, int)in glwidget.o
> "_glDeleteLists", referenced from:
> GLWidget::~GLWidget()in glwidget.o
> GLWidget::~GLWidget()in glwidget.o
> GLWidget::~GLWidget()in glwidget.o
> "GLWidget::yRotationChanged(int)", referenced from:
> GLWidget::setYRotation(int) in glwidget.o
> "_glBegin", referenced from:
> GLWidget::makeObject() in glwidget.o
> "_glNewList", referenced from:
> GLWidget::makeObject() in glwidget.o
> "_glVertex3d", referenced from:
> GLWidget::extrude(double, double, double, double)in glwidget.o
> GLWidget::extrude(double, double, double, double)in glwidget.o
> GLWidget::extrude(double, double, double, double)in glwidget.o
> GLWidget::extrude(double, double, double, double)in glwidget.o
> GLWidget::quad(double, double, double, double, double, double,
> double, double)in glwidget.o
> GLWidget::quad(double, double, double, double, double, double,
> double, double)in glwidget.o
> GLWidget::quad(double, double, double, double, double, double,
> double, double)in glwidget.o
> GLWidget::quad(double, double, double, double, double, double,
> double, double)in glwidget.o
> GLWidget::quad(double, double, double, double, double, double,
> double, double)in glwidget.o
> GLWidget::quad(double, double, double, double, double, double,
> double, double)in glwidget.o
> GLWidget::quad(double, double, double, double, double, double,
> double, double)in glwidget.o
> GLWidget::quad(double, double, double, double, double, double,
> double, double)in glwidget.o
> "vtable for Window", referenced from:
> __ZTV6Window$non_lazy_ptr in main.o
> __ZTV6Window$non_lazy_ptr in window.o
> "Window::staticMetaObject", referenced from:
> __ZN6Window16staticMetaObjectE$non_lazy_ptr in window.o
> "_glOrtho", referenced from:
> GLWidget::resizeGL(int, int)in glwidget.o
> "_glLoadIdentity", referenced from:
> GLWidget::paintGL() in glwidget.o
> GLWidget::resizeGL(int, int)in glwidget.o
> "_glClear", referenced from:
> GLWidget::paintGL() in glwidget.o
> "vtable for GLWidget", referenced from:
> __ZTV8GLWidget$non_lazy_ptr in glwidget.o
> "_glShadeModel", referenced from:
> GLWidget::initializeGL() in glwidget.o
> "_glTranslated", referenced from:
> GLWidget::paintGL() in glwidget.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
> make[2]: *** [exe] Error 1
> make[1]: *** [CMakeFiles/exe.dir/all] Error 2
> make: *** [all] Error 2
>
> I've also attached the source files, which are really simple Qt files if
> you are interested. Thank you very much for your reply.
>
> Linge
>
> On Fri, Sep 26, 2008 at 3:15 PM, <[EMAIL PROTECTED]> wrote:
> > It should simply be:
> >
> > PROJECT ( COMBINED )
> > FIND_PACKAGE (Qt4 REQUIRED)
> > SET(QT_USE_QTOPENGL TRUE)
> > INCLUDE( ${QT_USE_FILE} )
> > ADD_EXECUTABLE(exe main.cpp glwidget.cpp window.cpp)
> > TARGET_LINK_LIBRARIES(exe ${QT_LIBRARIES})
> >
> > Clint
> >
> > On Friday 26 September 2008 1:02:43 pm Linge Bai wrote:
> > > Hi everybody,
> > >
> > > I have a project developed by Qt4's OpenGL, for example plenty of usage
> >
> > of
>
Re: [CMake] [Paraview] Forcing a Qt version
I do multiple Qt versions simply by modifying my PATH before the first time I run cmake on an empty build directory. To verify that, I can run "qmake --version" from a console/terminal, to make sure its the right one before I run cmake for the first time. Clint On Tuesday 07 October 2008 4:38:50 pm Renato N. Elias wrote: > I gave up and employed the dirtiest solution. Deleted Qt 4.3.4 and used > Qt 4.4.2. Nothing more to choose, CMake finally got convinced that I > only have one Qt version... > > ...In the end, instead of forcing a Qt version CMake forced me to delete > one of them :o( > > Renato. > > Dominik Szczerba wrote: > > Yeah I used to fight with it too. It is far from clean. I do not recall > > now the details, but what did the trick for me was to specify > > QMAKE_EXECUTABLE (or something) and QT_DESIRED_VERSION (or something) > > > > Dominik > > > > On Tuesday 07 October 2008 05:11:56 pm Renato N. Elias wrote: > >> Michael and Clinton > >> > >> I guess I'm facing a CMake's bug. I'm actually working with two Qt4 > >> versions: Qt 4.4.2 (official distribution, including VS2008 integration) > >> and Qt 4.3.4 (open source distribution). I've set the QTDIR variable as > >> Michael suggested (in two places. Firstly in my own environment > >> variables and secondly in the system's variables) but it had not worked. > >> After that I downgraded CMake to 2.6.2 (official release), same problem. > >> > >> Clinton, setting the QT_QMAKE_EXECUTABLE in CMake was the first thing I > >> tried (take a look at here > >> http://www.nacad.ufrj.br/~rnelias/paraview/qt.JPG). It should be the > >> easiest way. CMake keeps my set but mix with the other Qt stuffs with > >> the newest version (4.4.2). Thus, when I try to launch the compiled PV I > >> get an error message saying that it's not possible to find the entry > >> point of the procedure [EMAIL PROTECTED]@@[EMAIL PROTECTED] in > >> dynamic library QtGui4.dll. My guess, is that Visual Studio is "qmaking" > >> with version 4.3.4 and linking against 4.4.2. > >> > >> By the way, should PV3 work with 4.4.2? Has anybody tried it? > >> > >> Regards > >> > >> Renato > >> > >> Clinton Stimpson wrote: > >>> If there's a qmake in your PATH, it takes precedence over whatever you > >>> set QTDIR to be. > >>> By the way, the use of QTDIR has been deprecated by Trolltech. > >>> Another thing you can do is set QT_QMAKE_EXECUTABLE in the cmake-gui > >>> before you hit configure for the first time, and it won't matter what > >>> your PATH is. > >>> > >>> Clint > >>> > >>> Michael Jackson wrote: > >>>> Renato > >>>>Assuming you really meant Qt 4.3.4 and NOT Qt 3.3.4 here is what > >>>> you need to do. > >>>> > >>>> Remove everything from your build directory so we can start clean. > >>>> Go to "My Computer" and add/check/set the QTDIR (Capitalization > >>>> counts) to your Qt 4 installation. > >>>> Launch CMakeSetup or CMake-GUI.exe and configure ParaView. You should > >>>> at most get a warning about the version of Qt your are using and the > >>>> "required" version. > >>>> > >>>> Everything _should_ work. > >>>> > >>>> Now, if you are really trying to use Qt 3 instead of Qt 4 then that > >>>> is not supported. YOu need at least Qt 4.3 to build ParaView. > >>>> > >>>> Mike Jackson > >>>> > >>>> On Oct 7, 2008, at 10:31 AM, Renato N. Elias wrote: > >>>>> Hi Michael, > >>>>> > >>>>> there's something overriding my QTDIR because CMake still points to > >>>>> the wrong Qt version. I've set both QT_QMAKE_EXECUTABLE and QTDIR to > >>>>> 3.3.4 version, but CMake still returns me a warning that I'm using > >>>>> an unsupported version of Qt. Now I'm trying to understand all that > >>>>> CMake sintaxe in FindQt4.cmake and UseQt4.cmake modules. > >>>>> > >>>>> weird, isn't it?! > >>>>> > >>>>> Renato. > >>>>> > >>>>> Michael Jackson wrote: > >>>>>> On Oct 7, 2008, at 9:26 AM, Renato N. Elias wrote: > >>>>>>&
Re: [CMake] Phonon with an older version of CMake
Are you even linking with the phonon library? Having CMake find them is one thing. Linking with them is another. Clint On Tuesday 28 October 2008 1:03:49 pm Alexander Solis wrote: > Hi, > > I tried CMake 2.6 a long time ago and don't remember the errors/ > warning, since it is a large project it was decided to use CMake 2.4 > instead. > > Using 2.4 cmake runs fine but when compiling (with make) I get the > following error: > Undefined symbols: >"Phonon::Path::~Path()", referenced from: >QtWizardList::load() in QtWizardList.o >QtWizardList::load() in QtWizardList.o >"Phonon::createPath(Phonon::MediaNode*, Phonon::MediaNode*)", > referenced from: >QtWizardList::load() in QtWizardList.o >QtWizardList::load() in QtWizardList.o >"Phonon::AudioOutput::AudioOutput(Phonon::Category, QObject*)", > referenced from: >QtWizardList::load() in QtWizardList.o >"Phonon::MediaObject::setTickInterval(int)", referenced from: >QtWizardList::load() in QtWizardList.o >"Phonon::MediaObject::MediaObject(QObject*)", referenced from: >QtWizardList::load() in QtWizardList.o >"Phonon::MediaObject::play()", referenced from: >QtWizardList::load() in QtWizardList.o >"Phonon::MediaObject::setCurrentSource(Phonon::MediaSource > const&)", referenced from: >QtWizardList::load() in QtWizardList.o >"Phonon::MediaSource::MediaSource(QString const&)", referenced from: >QtWizardList::load() in QtWizardList.o >"Phonon::VideoWidget::VideoWidget(QWidget*)", referenced from: >QtWizardList::load() in QtWizardList.o > ld: symbol(s) not found > collect2: ld returned 1 exit status > > On Oct 28, 2008, at 12:21 PM, Bill Hoffman wrote: > > Alexander Solis wrote: > >> Hi, > >> I am trying to compile an application that uses Qt4.4 Phonon's > >> libraries with CMake 2.4 patch 6. I am using Mac OS X 10.5 > >> I know that the version of CMake I am using doesn't include in the > >> modules a way to find Phonon, so I added the necessary lines to > >> find Phonon from CMake 2.6.2 file FindQt4.cmake. > >> The problem is that CMake is still not finding the Phonon libraries > >> after the change. > >> I am not sure if that is the only change I need to do to get Phonon > >> working with my version of CMake or if there is something else I > >> must do? > >> Note: I cannot use CMake 2.6 since I get a lot of errors trying to > >> run it, so that is why I need to use the older CMake version. > > > > Are they errors or warnings when you run 2.6? What are some of the > > errors you get? > > > > -Bill > > ___ > CMake mailing list > CMake@cmake.org > http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Phonon with an older version of CMake
It don't see you linking with phonon.
Its typically done like this (using phonon support in CMake 2.6)
find_package(Qt4)
set(QT_USE_PHONON 1)
include(${QT_USE_FILE})
add_executable(...)
target_link_libraries(... ${QT_LIBRARIES})
Clint
On Tuesday 28 October 2008 3:03:25 pm Alexander Solis wrote:
> Ok, here are the results from the testing program I wrote.
>
> It looks like both CMake 2.4 and CMake 2.6 have the same problem with
> Phonon.
>
> Here is with CMake 2.4:
>
> /opt/local/bin/cmake -H/Users/telcentrisholdingsa/Desktop/video_cmake -
> B/Users/telcentrisholdingsa/Desktop/video_cmake --check-build-system
> CMakeFiles/Makefile.cmake 0
> /opt/local/bin/cmake -E cmake_progress_start /Users/
> telcentrisholdingsa/Desktop/video_cmake/CMakeFiles /Users/
> telcentrisholdingsa/Desktop/video_cmake/CMakeFiles/progress.make
> make -f CMakeFiles/Makefile2 all
> make -f CMakeFiles/video.dir/build.make CMakeFiles/video.dir/depend
> /opt/local/bin/cmake -E cmake_progress_report /Users/
> telcentrisholdingsa/Desktop/video_cmake/CMakeFiles 4
> [ 25%] Generating moc_mainwindow.cxx
> /usr/local/Trolltech/Qt-4.4.0/bin/moc -I/usr/local/Trolltech/Qt-4.4.0/
> include -I/usr/local/Trolltech/Qt-4.4.0/include/QtGui -I/usr/local/
> Trolltech/Qt-4.4.0/include/QtCore -DQT_DLL -DQT_GUI_LIB -DQT_CORE_LIB -
> o /Users/telcentrisholdingsa/Desktop/video_cmake/moc_mainwindow.cxx /
> Users/telcentrisholdingsa/Desktop/video_cmake/mainwindow.h
> cd /Users/telcentrisholdingsa/Desktop/video_cmake && /opt/local/bin/
> cmake -E cmake_depends "Unix Makefiles" /Users/telcentrisholdingsa/
> Desktop/video_cmake /Users/telcentrisholdingsa/Desktop/video_cmake /
> Users/telcentrisholdingsa/Desktop/video_cmake /Users/
> telcentrisholdingsa/Desktop/video_cmake /Users/telcentrisholdingsa/
> Desktop/video_cmake/CMakeFiles/video.dir/DependInfo.cmake --color=
> Dependee "/Users/telcentrisholdingsa/Desktop/video_cmake/CMakeFiles/
> video.dir/DependInfo.cmake" is newer than depender "/Users/
> telcentrisholdingsa/Desktop/video_cmake/CMakeFiles/video.dir/
> depend.internal".
> Scanning dependencies of target video
> make -f CMakeFiles/video.dir/build.make CMakeFiles/video.dir/build
> /opt/local/bin/cmake -E cmake_progress_report /Users/
> telcentrisholdingsa/Desktop/video_cmake/CMakeFiles 1
> [ 50%] Building CXX object CMakeFiles/video.dir/mainwindow.o
> /usr/bin/c++ -DQT_DLL -DQT_GUI_LIB -DQT_CORE_LIB -DQT_NO_DEBUG -I/
> usr/local/Trolltech/Qt-4.4.0/include -I/usr/local/Trolltech/Qt-4.4.0/
> include/QtGui -I/usr/local/Trolltech/Qt-4.4.0/include/QtCore -F/usr/
> local/Trolltech/Qt-4.4.0/lib -o CMakeFiles/video.dir/mainwindow.o -c /
> Users/telcentrisholdingsa/Desktop/video_cmake/mainwindow.cpp
> /opt/local/bin/cmake -E cmake_progress_report /Users/
> telcentrisholdingsa/Desktop/video_cmake/CMakeFiles 2
> [ 75%] Building CXX object CMakeFiles/video.dir/main.o
> /usr/bin/c++ -DQT_DLL -DQT_GUI_LIB -DQT_CORE_LIB -DQT_NO_DEBUG -I/
> usr/local/Trolltech/Qt-4.4.0/include -I/usr/local/Trolltech/Qt-4.4.0/
> include/QtGui -I/usr/local/Trolltech/Qt-4.4.0/include/QtCore -F/usr/
> local/Trolltech/Qt-4.4.0/lib -o CMakeFiles/video.dir/main.o -c /Users/
> telcentrisholdingsa/Desktop/video_cmake/main.cpp
> /opt/local/bin/cmake -E cmake_progress_report /Users/
> telcentrisholdingsa/Desktop/video_cmake/CMakeFiles 3
> [100%] Building CXX object CMakeFiles/video.dir/moc_mainwindow.o
> /usr/bin/c++ -DQT_DLL -DQT_GUI_LIB -DQT_CORE_LIB -DQT_NO_DEBUG -I/
> usr/local/Trolltech/Qt-4.4.0/include -I/usr/local/Trolltech/Qt-4.4.0/
> include/QtGui -I/usr/local/Trolltech/Qt-4.4.0/include/QtCore -F/usr/
> local/Trolltech/Qt-4.4.0/lib -o CMakeFiles/video.dir/moc_mainwindow.o
> -c /Users/telcentrisholdingsa/Desktop/video_cmake/moc_mainwindow.cxx
> Linking CXX executable video
> /opt/local/bin/cmake -E cmake_link_script CMakeFiles/video.dir/
> link.txt --verbose=1
> /usr/bin/c++-Wl,-search_paths_first -headerpad_max_install_names -
> fPIC CMakeFiles/video.dir/mainwindow.o CMakeFiles/video.dir/main.o
> CMakeFiles/video.dir/moc_mainwindow.o -o video -F/usr/local/
> Trolltech/Qt-4.4.0/lib -framework QtGui -framework Carbon -framework
> AppKit -framework QtCore /usr/lib/libz.dylib -framework
> ApplicationServices
> Undefined symbols:
>"Phonon::MediaObject::setCurrentSource(Phonon::MediaSource
> const&)", referenced from:
>MainWindow::MainWindow()in mainwindow.o
>"Phonon::AudioOutput::AudioOutput(Phonon::Category, QObject*)",
> referenced from:
>MainWindow::MainWindow()in mainwindow.o
>"Phonon::VideoWidget::VideoWidget(QWidget*)", referenced from:
>MainWindow::MainWindow()in mainwindow.o
>"Phonon::MediaObject::play()", referenced from:
>MainWindow::MainWindow()in mainwindow.o
>"Phonon::MediaSource::MediaSource(QString const&)", referenced from:
>MainWindow::MainWindow()in mainwindow.o
>"Phonon::MediaObject::MediaObject(QObject*)", referenced from:
>MainWindow::MainWindow()in mainwindow.o
>"Phonon
Re: [CMake] CMake 2.6.2 can't find QtCore
What does "qmake -query QT_INSTALL_LIBS" give you?
Do you even have a /usr/lib/libQtCore.so? Or something like that?
Clint
On Wednesday 05 November 2008 9:36:45 am Serhii Piddubchak wrote:
> Hello, I'm using OpenSUSE 11.0 and trying to build software that uses QT.
> I have QT and QT-devel packages installed but CMake says it Can't find
> QtCore. I've posted a question about this to a project's forum here:
>
> http://www.hedgewars.org/forum/viewtopic.php?id=648
>
> They said it could be a CMake bug.
> Here is the log(versions of cmake and qt are included):
>
> [EMAIL PROTECTED]:~/builds> tar jxf ~/downloads/hedgewars-src-0.9.7.tar.bz2
> [EMAIL PROTECTED]:~/builds> cd hedgewars-src-0.9.7/
> [EMAIL PROTECTED]:~/builds/hedgewars-src-0.9.7> cmake .
> -- The C compiler identification is GNU
> -- The CXX compiler identification is GNU
> -- Check for working C compiler: /usr/bin/gcc
> -- Check for working C compiler: /usr/bin/gcc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Looking for Q_WS_X11
> -- Looking for Q_WS_X11 - found
> -- Looking for Q_WS_WIN
> -- Looking for Q_WS_WIN - not found.
> -- Looking for Q_WS_QWS
> -- Looking for Q_WS_QWS - not found.
> -- Looking for Q_WS_MAC
> -- Looking for Q_WS_MAC - not found.
> CMake Error at /usr/share/cmake/Modules/FindQt4.cmake:788 (MESSAGE):
> Could NOT find QtCore. Check
> /home/dusoft/builds/hedgewars-src-0.9.7/CMakeFiles/CMakeError.log for
> more details.
> Call Stack (most recent call first):
> QTfrontend/CMakeLists.txt:11 (find_package)
>
>
> -- Configuring incomplete, errors occurred!
> [EMAIL PROTECTED]:~/builds/hedgewars-src-0.9.7> cmake --version
> cmake version 2.6-patch 2
> [EMAIL PROTECTED]:~/builds/hedgewars-src-0.9.7> cat
> CMakeFiles/CMakeError.log Determining if the Q_WS_WIN exist failed with the
> following output: Change Dir:
> /home/dusoft/builds/hedgewars-src-0.9.7/CMakeFiles/CMakeTmp
>
> Run Build Command:/usr/bin/gmake "cmTryCompileExec/fast"
> /usr/bin/gmake -f CMakeFiles/cmTryCompileExec.dir/build.make
> CMakeFiles/cmTryCompileExec.dir/build
> gmake[1]: Entering directory
> `/home/dusoft/builds/hedgewars-src-0.9.7/CMakeFiles/CMakeTmp'
> /usr/bin/cmake -E cmake_progress_report
> /home/dusoft/builds/hedgewars-src-0.9.7/CMakeFiles/CMakeTmp/CMakeFiles
> 1
> Building C object CMakeFiles/cmTryCompileExec.dir/CheckSymbolExists.c.o
> /usr/bin/gcc-o
> CMakeFiles/cmTryCompileExec.dir/CheckSymbolExists.c.o -c
> /home/dusoft/builds/hedgewars-src-0.9.7/CMakeFiles/CMakeTmp/CheckSymbolExis
>ts.c
> /home/dusoft/builds/hedgewars-src-0.9.7/CMakeFiles/CMakeTmp/CheckSymbolExis
>ts.c: In function 'main':
> /home/dusoft/builds/hedgewars-src-0.9.7/CMakeFiles/CMakeTmp/CheckSymbolExis
>ts.c:8: error: 'Q_WS_WIN' undeclared (first use in this function)
> /home/dusoft/builds/hedgewars-src-0.9.7/CMakeFiles/CMakeTmp/CheckSymbolExis
>ts.c:8: error: (Each undeclared identifier is reported only once
> /home/dusoft/builds/hedgewars-src-0.9.7/CMakeFiles/CMakeTmp/CheckSymbolExis
>ts.c:8: error: for each function it appears in.)
> gmake[1]: *** [CMakeFiles/cmTryCompileExec.dir/CheckSymbolExists.c.o] Error
> 1 gmake[1]: Leaving directory
> `/home/dusoft/builds/hedgewars-src-0.9.7/CMakeFiles/CMakeTmp'
> gmake: *** [cmTryCompileExec/fast] Error 2
>
> File
> /home/dusoft/builds/hedgewars-src-0.9.7/CMakeFiles/CMakeTmp/CheckSymbolExis
>ts.c: /* */
> #include
>
> void cmakeRequireSymbol(int dummy,...){(void)dummy;}
> int main()
> {
> #ifndef Q_WS_WIN
> cmakeRequireSymbol(0,&Q_WS_WIN);
> #endif
> return 0;
> }
>
> Determining if the Q_WS_QWS exist failed with the following output:
> Change Dir: /home/dusoft/builds/hedgewars-src-0.9.7/CMakeFiles/CMakeTmp
>
> Run Build Command:/usr/bin/gmake "cmTryCompileExec/fast"
> /usr/bin/gmake -f CMakeFiles/cmTryCompileExec.dir/build.make
> CMakeFiles/cmTryCompileExec.dir/build
> gmake[1]: Entering directory
> `/home/dusoft/builds/hedgewars-src-0.9.7/CMakeFiles/CMakeTmp'
> /usr/bin/cmake -E cmake_progress_report
> /home/dusoft/builds/hedgewars-src-0.9.7/CMakeFiles/CMakeTmp/CMakeFiles
> 1
> Building C object CMakeFiles/cmTryCompileExec.dir/CheckSymbolExists.c.o
> /usr/bin/gcc-o
> CMakeFiles/cmTryCompileExec.dir/CheckSymbolExists.c.o -c
> /home/dusoft/builds/hedgewars-src-0.9.7/CMakeFiles/CMakeTmp/CheckSymbolExis
>ts.c
> /home/dusoft/builds/hedgewars-src-0.9.7/CMakeFiles/CMakeTmp/CheckSymbolExis
>ts.c: In function 'main':
> /home/dusoft/builds/hedgewars-src-0.9.7/CMakeFiles/CMakeTmp/CheckSymbolExis
>ts.c:8: error: 'Q_WS_QWS' undeclared (first use in this function)
> /home/dusoft/builds/hedgewars-src-0.9.7/CMakeFiles/CMakeTmp/CheckSymbolExis
>ts.c:8: error: (Each undeclared identifier is reported only once
> /home/dusoft/builds/hedgewars-src-0.9.7/CMakeFiles/CMakeTmp/CheckSymbolExis
>ts.c:8: err
Re: [CMake] CMake 2.6.2 can't find QtCore
Your /usr/lib/libQtCore.so is a broken softlink to a file that doesn't exist.
Something is wrong with your Qt installation.
Clint
On Wednesday 05 November 2008 12:53:01 pm Serhii Piddubchak wrote:
> [EMAIL PROTECTED]:/var/media/games> qmake -query QT_INSTALL_LIBS
> /usr/lib
> [EMAIL PROTECTED]:/var/media/games> ls -lh /usr/lib/libQtCore*
> -rw-r--r-- 1 root root 687 2008-09-19 19:27 /usr/lib/libQtCore.la
> -rw-r--r-- 1 root root 633 2008-09-19 19:27 /usr/lib/libQtCore.prl
> lrwxrwxrwx 1 root root 18 2008-10-26 23:50 /usr/lib/libQtCore.so ->
> libQtCore.so.4.4.0
> lrwxrwxrwx 1 root root 18 2008-10-30 11:24 /usr/lib/libQtCore.so.4
> -> libQtCore.so.4.4.3
> lrwxrwxrwx 1 root root 18 2008-10-30 11:24 /usr/lib/libQtCore.so.4.4
> -> libQtCore.so.4.4.3
> -rwxr-xr-x 1 root root 2.2M 2008-10-12 19:01 /usr/lib/libQtCore.so.4.4.3
>
> 2008/11/5 <[EMAIL PROTECTED]>:
> > What does "qmake -query QT_INSTALL_LIBS" give you?
> > Do you even have a /usr/lib/libQtCore.so? Or something like that?
> >
> > Clint
> >
> > On Wednesday 05 November 2008 9:36:45 am Serhii Piddubchak wrote:
> >> Hello, I'm using OpenSUSE 11.0 and trying to build software that uses
> >> QT. I have QT and QT-devel packages installed but CMake says it Can't
> >> find QtCore. I've posted a question about this to a project's forum
> >> here:
> >>
> >> http://www.hedgewars.org/forum/viewtopic.php?id=648
> >>
> >> They said it could be a CMake bug.
> >> Here is the log(versions of cmake and qt are included):
> >>
> >> [EMAIL PROTECTED]:~/builds> tar jxf
> >> ~/downloads/hedgewars-src-0.9.7.tar.bz2 [EMAIL PROTECTED]:~/builds> cd
> >> hedgewars-src-0.9.7/
> >> [EMAIL PROTECTED]:~/builds/hedgewars-src-0.9.7> cmake .
> >> -- The C compiler identification is GNU
> >> -- The CXX compiler identification is GNU
> >> -- Check for working C compiler: /usr/bin/gcc
> >> -- Check for working C compiler: /usr/bin/gcc -- works
> >> -- Detecting C compiler ABI info
> >> -- Detecting C compiler ABI info - done
> >> -- Check for working CXX compiler: /usr/bin/c++
> >> -- Check for working CXX compiler: /usr/bin/c++ -- works
> >> -- Detecting CXX compiler ABI info
> >> -- Detecting CXX compiler ABI info - done
> >> -- Looking for Q_WS_X11
> >> -- Looking for Q_WS_X11 - found
> >> -- Looking for Q_WS_WIN
> >> -- Looking for Q_WS_WIN - not found.
> >> -- Looking for Q_WS_QWS
> >> -- Looking for Q_WS_QWS - not found.
> >> -- Looking for Q_WS_MAC
> >> -- Looking for Q_WS_MAC - not found.
> >> CMake Error at /usr/share/cmake/Modules/FindQt4.cmake:788 (MESSAGE):
> >> Could NOT find QtCore. Check
> >> /home/dusoft/builds/hedgewars-src-0.9.7/CMakeFiles/CMakeError.log for
> >> more details.
> >> Call Stack (most recent call first):
> >> QTfrontend/CMakeLists.txt:11 (find_package)
> >>
> >>
> >> -- Configuring incomplete, errors occurred!
> >> [EMAIL PROTECTED]:~/builds/hedgewars-src-0.9.7> cmake --version
> >> cmake version 2.6-patch 2
> >> [EMAIL PROTECTED]:~/builds/hedgewars-src-0.9.7> cat
> >> CMakeFiles/CMakeError.log Determining if the Q_WS_WIN exist failed with
> >> the following output: Change Dir:
> >> /home/dusoft/builds/hedgewars-src-0.9.7/CMakeFiles/CMakeTmp
> >>
> >> Run Build Command:/usr/bin/gmake "cmTryCompileExec/fast"
> >> /usr/bin/gmake -f CMakeFiles/cmTryCompileExec.dir/build.make
> >> CMakeFiles/cmTryCompileExec.dir/build
> >> gmake[1]: Entering directory
> >> `/home/dusoft/builds/hedgewars-src-0.9.7/CMakeFiles/CMakeTmp'
> >> /usr/bin/cmake -E cmake_progress_report
> >> /home/dusoft/builds/hedgewars-src-0.9.7/CMakeFiles/CMakeTmp/CMakeFiles
> >> 1
> >> Building C object CMakeFiles/cmTryCompileExec.dir/CheckSymbolExists.c.o
> >> /usr/bin/gcc-o
> >> CMakeFiles/cmTryCompileExec.dir/CheckSymbolExists.c.o -c
> >> /home/dusoft/builds/hedgewars-src-0.9.7/CMakeFiles/CMakeTmp/CheckSymbolE
> >>xis ts.c
> >> /home/dusoft/builds/hedgewars-src-0.9.7/CMakeFiles/CMakeTmp/CheckSymbolE
> >>xis ts.c: In function 'main':
> >> /home/dusoft/builds/hedgewars-src-0.9.7/CMakeFiles/CMakeTmp/CheckSymbolE
> >>xis ts.c:8: error: 'Q_WS_WIN' undeclared (first use in this function)
> >> /home/dusoft/builds/hedgewars-src-0.9.7/CMakeFiles/CMakeTmp/CheckSymbolE
> >>xis ts.c:8: error: (Each undeclared identifier is reported only once
> >> /home/dusoft/builds/hedgewars-src-0.9.7/CMakeFiles/CMakeTmp/CheckSymbolE
> >>xis ts.c:8: error: for each function it appears in.)
> >> gmake[1]: *** [CMakeFiles/cmTryCompileExec.dir/CheckSymbolExists.c.o]
> >> Error 1 gmake[1]: Leaving directory
> >> `/home/dusoft/builds/hedgewars-src-0.9.7/CMakeFiles/CMakeTmp'
> >> gmake: *** [cmTryCompileExec/fast] Error 2
> >>
> >> File
> >> /home/dusoft/builds/hedgewars-src-0.9.7/CMakeFiles/CMakeTmp/CheckSymbolE
> >>xis ts.c: /* */
> >> #include
> >>
> >> void cmakeRequireSymbol(int dummy,...){(void)dummy;}
> >> int main()
> >> {
> >> #ifndef Q_WS_WIN
> >> cmakeRequireSymbol(0,&Q_WS_WIN);
> >> #endif
> >> return 0;
> >> }
> >>
> >> Determining if the Q_WS_QWS exist failed with the following output:
Re: [CMake] making Nightly builds easier to setup
If you don't want to overwrite the CMakeCache.txt file, you can do the
following instead of a FILE(WRITE...). This also works if you don't have an
initial CMakeCache.txt file.
SET(FORCED_CACHE_VALUES
\"-DCMAKE_OSX_ARCHITECTURES:STRING=i386;ppc\"
\"-DCMAKE_BUILD_TYPE:STRING=Release\"
)
STRING(REGEX REPLACE "\";" "\" " FORCED_CACHE_VALUES "${FORCED_CACHE_VALUES}")
SET(CTEST_CONFIGURE_COMMAND "\"${CTEST_CMAKE_COMMAND}\" ${FORCED_CACHE_VALUES}
\"${CTEST_SOURCE_DIRECTORY}\"")
CTEST_CONFIGURE(BUILD "${CTEST_BINARY_DIRECTORY}" RETURN_VALUE config_result)
Clint
On Monday 10 November 2008 9:44:43 am David Cole wrote:
> The variable CTEST_INITIAL_CACHE is ignored in new-style (CTEST_BUILD()
> command based) ctest scripts.
> Instead, you should use:
>
> FILE(WRITE "${CTEST_BINARY_DIRECTORY}/CMakeCache.txt" "
> MAKECOMMAND:STRING=nmake -i
> CMAKE_MAKE_PROGRAM:FILEPATH=nmake
> CMAKE_GENERATOR:INTERNAL=NMake Makefiles
> BUILDNAME:STRING=Win32-nmake71
> SITE:STRING=VOGON.kitware
> CVSCOMMAND:FILEPATH=C:/cygwin/bin/cvs.exe
> ")
>
> (But only on a clean build, after calling
> CTEST_EMPTY_BINARY_DIRECTORY("${CTEST_BINARY_DIRECTORY}"), or perhaps only
> if the CMakeCache.txt does not exist in the first place...)
>
> HTH,
> David
>
> On Mon, Nov 10, 2008 at 5:33 AM, Martin Apel <[EMAIL PROTECTED]> wrote:
> > Eric Noulard wrote:
> > > 2008/11/9 Alexander Neundorf <[EMAIL PROTECTED]>:
> > > [...]
> > >
> > >> commands can be executed.
> > >>
> > >> IMO this can make setting up Nightly builds much easier.
> > >
> > > Looks interesting, I didn't ever thought ctest scripting was done for
> >
> > that.
> >
> > > I did shell scripts for that and was wondering how to do it on Windows
> > >
> > :-)
> > :
> > > Now I know.
> > >
> > >> What do you think ?
> > >> One thing which is still missing is a way how to get variables
> >
> > predefined into
> >
> > >> the cmake-configure run during ctest_configure().
> > >> Does this have to be done by writing an initial CMakeCache.txt ?
> > >
> > > This seems possible using "CTEST_INITIAL_CACHE"
> > > as shown here:
> > > http://www.vtk.org/Wiki/CMake_Scripting_Of_CTest
> > >
> > > # this is the initial cache to use for the binary tree, be careful to
> >
> > escape
> >
> > > # any quotes inside of this string if you use it
> > > SET (CTEST_INITIAL_CACHE "
> > > MAKECOMMAND:STRING=nmake -i
> > > CMAKE_MAKE_PROGRAM:FILEPATH=nmake
> > > CMAKE_GENERATOR:INTERNAL=NMake Makefiles
> > > BUILDNAME:STRING=Win32-nmake71
> > > SITE:STRING=VOGON.kitware
> > > CVSCOMMAND:FILEPATH=C:/cygwin/bin/cvs.exe
> > > ")
> >
> > I recently played around with nightly builds as well. I used to have a
> > setup for experimental builds, but never could get the svn checkout to
> > run. With the approach described above, I was finally able
> > to run checkout from svn from within ctest. Unfortunately it seems that
> > some variables are not used anymore with this approach of generating
> > builds.
> > I found that CTEST_INITIAL_CACHE as well as CTEST_ENVIRONMENT seem to be
> > ignored, when using CTEST_BUILD etc. For the environment variables I
> > could get it to work by setting
> > the environment variables explicitly, e.g. 'SET (ENV{CC} "gcc-4.2")'.
> > That means that the approach proposed above does not work, at least not
> > for me.
> >
> > After all I'm somewhat confused about this new approach ignoring some of
> > the variables. Maybe someone with a deeper knowledge of ctest could
> > explain, what's going on here.
> >
> > Regards,
> >
> > Martin
> >
> > Virus checked by G DATA AntiVirus
> > Version: AVF 19.138 from 09.11.2008
> >
> >
> > ___
> > CMake mailing list
> > CMake@cmake.org
> > http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Building Qt app
This should answer your questions about it. A patch is also provided. http://trolltech.com/developer/task-tracker/index_html?id=228612&method=entry Clint - Original Message - From: "kafou nmento" To: cmake@cmake.org Sent: Tuesday, December 23, 2008 10:23:26 AM GMT -07:00 US/Canada Mountain Subject: [CMake] Building Qt app Hi all! I'm building a Qt based app with CMake using MinGW generator. I set this in my CMakeLists.txt : SET(QT_USE_QTDESIGNER 1) SET(QT_USE_QTMAIN 1) SET(QT_USE_QTUITOOLS 1) SET(QT_USE_QTWEBKIT 1) When building I errors like below : C:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/winbase.h:1663: error: declaration of C function `LONG InterlockedCompareExchange(volatile LONG*, LONG , LONG)' conflicts with C:/Qt/4.4.3/include/QtCore/../../src/corelib/arch/qatomic_windows.h:387: error: previous declaration `long int InterlockedCompareExchange(long int*, long int, l ong int)' here Is there anyboy who can help me? Thanks in advance. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] dependency in custom command?
>> You don't have to do the copying yourself. Just tell CMake in which
>> directory it should create the module by either setting the
>> LIBRARY_OUTPUT_DIRECTORY target property or the
>> CMAKE_LIBRARY_OUTPUT_DIRECTORY variable.
>>
>> AFAIK the LOCATION property is only present for compatibility with
>> CMake 2.4, and shouldn't be used in new code.
> Hi Mike -- I don't know from which directory my module test will run when
> using ctest. So, my test program does not have an easy way to know the
> relative path to LIBRARY_OUTPUT_DIRECTORY when making the dlopen() call.
> Allowing my test program to assume the dll is in its local directory
> seemed to be the easiest solution.
Can't you put all executables and shared libraries in one directory, so they
are all local to each other?
In the top level CMakeLists.txt file just add
SET(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
SET(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
The executables you specify in ADD_TEST() will have a working directory that is
${CMAKE_CURRENT_BINARY_DIR}
Clint
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindQt in a Specific place?
I've also seen people put a qt.conf file in the Qt installation, to override
the compiled-in paths.
That's probably how its done by the Windows installer.
Clint
- Michael Jackson wrote:
> Um, yea, you don't want to do that, change the location of the Qt
> libraries after they are built in one location. On Windows, the only
> way you can do that (to my knowledge) is to use the MinGW precompiled
> binaries from Nokia. When the installer runs all the paths are updated
> for the install location. As far as I can tell, Nokia has not released
> the installer build scripts for Qt built under Visual Studio. You seem
> to need a commercial license for that.
>
> So, With Qt, Pick a location where EVERYONE can have Qt installed,
> build it in THAT location, then you can move the installation from
> computer to computer. Yes, it sucks.
> _
> Mike Jackson mike.jack...@bluequartz.net
>
>
> On Jan 13, 2010, at 3:07 PM, James Willis wrote:
>
> > So:
> > set (QT_QMAKE_EXECUTABLE "${mySrc}/ExternalLibs/Qt/qt_current/bin/
> > qmake")
> >
> > This initially worked. But only initially. Then I did something
> > dastardly: I got rid of the original place I compiled the libraries
> > -- which qmake still somehow knows despite being compiled with -no-
> > rpath.
> >
> > Now I get this error:
> > Warning: QT_QMAKE_EXECUTABLE reported QT_INSTALL_LIBS as /home/
> > myName/qt-everywhere-commercial-src-4.6.0/Release/lib
> > Warning: /home/myName/qt-everywhere-commercial-src-4.6.0/Release/lib
> > does NOT exist, Qt must NOT be installed correctly.
> > CMake Error at /home/jwillis/cmake-2.8.0/Modules/FindQt4.cmake:673
> > (MESSAGE):
> > Could NOT find QtCore header
> >
> > I also tried Tyler's idea, which fails in exactly the same way, with
> > the same error.
> >
> > The idea here is my group has people who may want to compile the
> > code elsewhere on various different machines without installing any
> > libraries. We're dependent on a bunch right now, and it's a pain
> > for each developer to have to get the right version of the right
> > libraries, in the right order, to compile on their machine. So we
> > just stick already compiled versions in a seperate libs
> > directories. And no, we'd actually prefer their location set in the
> > cmakefile so we can change centrally when we decide to upgrade
> > libraries.
> >
> > Thanks for the help so far, but I'm still hacking away at the moment.
> >
> > --James
> >
> >
> > From: Dave Partyka [dave.part...@kitware.com]
> > Sent: Wednesday, January 13, 2010 1:01 PM
> > To: James Willis
> > Cc: cmake@cmake.org
> > Subject: Re: [CMake] FindQt in a Specific place?
> >
> > I think if you set these two variables you will get the same desired
> > result.
> >
> >
> > set(DESIRED_QT_VERSION 4)
> > set(QT_QMAKE_EXECUTABLE /home/qt/4.6.0/bin/qmake)
> >
> > On Wed, Jan 13, 2010 at 1:07 PM, James Willis
> > mailto:jwill...@lgc.com
> > >> wrote:
> > Is there any good way of telling findqt (I don't really care about
> > findqt3) where to find Qt?
> >
> > Like say you did:
> > set(QT_QMAKE_LOCATION /home/myself/qt4.6.0/bin)
> > so that I later upgrade and do:
> > set(QT_QMAKE_LOCATION /home/myself/qt4.6.1/bin) later without having
> > to muck with my path, but still have findQt find Qt there?
> >
> > I was looking at writing such a feature, if it's not there, and if
> > you'd be willing to take it as a patch.
> >
> > --James
> >
> >
> > --
> > This e-mail, including any attached files, may contain confidential
> > and privileged information for the sole use of the intended
> > recipient. Any review, use, distribution, or disclosure by others
> > is strictly prohibited. If you are not the intended recipient (or
> > authorized to receive information for the intended recipient),
> > please contact the sender by reply e-mail and delete all copies of
> > this message.
> > ___
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at
> > http://www.kitware.com/opensource/opensource.html
> >
> > Please keep messages on-topic and check the CMake FAQ at:
> > http://www.cmake.org/Wiki/CMake_FAQ
> >
> > Follow this link to subscribe/unsubscribe:
> > http://www.cmake.org/mailman/listinfo/cmake
> >
> > ___
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at
> > http://www.kitware.com/opensource/opensource.html
> >
> > Please keep messages on-topic and check the CMake FAQ at:
> > http://www.cmake.org/Wiki/CMake_FAQ
> >
> > Follow this link to subscribe/unsubscribe:
> > http://www.cmake.org/mailman/listinfo/cmake
>
> ___
> Powered by www.kitwa
[CMake] Re: [Paraview] PV3/OS X/Qt 4.3 Compile error
http://public.kitware.com/Bug/view.php?id=5745
contains the bug report and the fix in patch format.
Clint
On Tuesday 18 September 2007 2:07:31 pm Mike Jackson wrote:
> #
>#
># Find out what window system we're using
>#
>#
># Save required includes variable
>SET(CMAKE_REQUIRED_INCLUDES_SAVE ${CMAKE_REQUIRED_INCLUDES})
># Add QT_INCLUDE_DIR to CMAKE_REQUIRED_INCLUDES
>SET(CMAKE_REQUIRED_INCLUDES "${CMAKE_REQUIRED_INCLUDES};$
> {QT_INCLUDE_DIR}")
>IF (QT_USE_FRAMEWORKS)
> SET(CMAKE_REQUIRED_FLAGS_SAVE ${CMAKE_REQUIRED_FLAGS})
> SET(CMAKE_REQUIRED_FLAGS "-F${QT_LIBRARY_DIR}")
>ENDIF (QT_USE_FRAMEWORKS)
>
># Check for Window system symbols (note: only one should end up
> being set)
>CHECK_SYMBOL_EXISTS(Q_WS_X11 "QtCore/qglobal.h" Q_WS_X11)
>CHECK_SYMBOL_EXISTS(Q_WS_MAC "QtCore/qglobal.h" Q_WS_MAC)
>CHECK_SYMBOL_EXISTS(Q_WS_WIN "QtCore/qglobal.h" Q_WS_WIN)
>
>IF (QT_QTCOPY_REQUIRED)
> CHECK_SYMBOL_EXISTS(QT_IS_QTCOPY "QtCore/qglobal.h"
> QT_KDE_QT_COPY)
> IF (NOT QT_IS_QTCOPY)
> MESSAGE(FATAL_ERROR "qt-copy is required, but hasn't been
> found")
> ENDIF (NOT QT_IS_QTCOPY)
>ENDIF (QT_QTCOPY_REQUIRED)
>
># Restore CMAKE_REQUIRED_INCLUDES variable
>SET(CMAKE_REQUIRED_INCLUDES ${CMAKE_REQUIRED_INCLUDES_SAVE})
>IF (QT_USE_FRAMEWORKS)
> SET(CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS_SAVE})
>ENDIF (QT_USE_FRAMEWORKS)
>#
>#
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Problem with Qt4 and release mode on windows
> > when I compile a qt plugin in release mode (and therefore link against > release qt lib) I've the problem that cmake does not set -DQT_NO_DEBUG . In any file you use the Q_EXPORT_PLUGIN2 macro, you can put something like this: #if defined(NDEBUG) # define QT_NO_DEBUG #endif at the top of the file. I don't see a way to do something like ADD_DEFINTIONS(-DQT_NO_DEBUG) for a release configuration only. Clint ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake failing to find QApplication header
>
> I have a top level CMakeList.txt file containing:
>
> FIND_PACKAGE(Qt4 REQUIRED)
> .
> .
> INCLUDE_DIRECTORIES(${QT_QTCORE_INCLUDE_DIR})
> INCLUDE_DIRECTORIES(${QT_QTGUI_INCLUDE_DIR})
> INCLUDE_DIRECTORIES(${QT_QTNETWORK_INCLUDE_DIR})
> INCLUDE_DIRECTORIES(${QT_QTSQL_INCLUDE_DIR})
Its easier to do this
FIND_PACKAGE(Qt4 REQUIRED)
SET(QT_USE_QTNETWORK TRUE)
SET(QT_USE_QTSQL TRUE)
INCLUDE(${QT_USE_FILE})
So the 'use' file will set up the preprocessor defines and set up what
libraries to link with.
Like this:
TARGET_LINK_LIBRARIES(myapp ${QT_LIBRARIES})
If that doesn't fix your problem, perhaps you should check your CMakeCache.txt
file to make sure it has the right path for the QT*INCLUDE_DIR variables.
Clint
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] QtDialog isn't installed?
> As you've noted, install rules to install it and its dependent components
> from Qt are lacking.
There's an install command now for the executable. If building with a static
Qt, that's probably all that is needed for distribution.
> I do not know if there is anything else "unfinished"
> in it. I'll let Clinton answer that question if he's listening.
My TODO list for the first cut has nothing left on it.
Having testers now to find any bugs would be nice.
I made an install of it last week on my machine and have been using it for
most of my builds since.
Clint
>
> It will be done and included when CMake 2.6 becomes available. (According
> to this thread,
> http://www.cmake.org/pipermail/cmake/2007-November/017715.html, CMake
> 2.6 and the new book should both be available in January...)
>
> HTH,
> David
>
> On 11/19/07, Miguel A. Figueroa-Villanueva <[EMAIL PROTECTED]> wrote:
> > On Nov 19, 2007 11:02 AM, David Cole wrote:
> > > Yes. Still in development. When it's "done" it will be added as an
> >
> > installed
> >
> > > entity...
> >
> > What features is it still missing? Is there a TODO list somewhere so
> > that I can track it's development? In any case, I'll be using it from
> > now on, so if testers is all that is needed I'll do that.
> >
> > --Miguel
> >
> > > On 11/19/07, Miguel A. Figueroa-Villanueva wrote:
> > > > Hello,
> > > >
> > > > First of all I'd like to say that the QtDialog implementation looks
> > > > pretty nice and I already prefer it to the current CMakeSetup in
> > > > winxp. Having a GUI like that in a cross-platform way makes it even
> > > > better! Thanks.
> > > >
> > > > Now, I haven't tried it in linux yet, but in windows it seems very
> > > > functional... why isn't it set to be installed? That is, it doesn't
> > > > get installed in the ${CMAKE_INSTALL_PREFIX}/bin directory... Is this
> > > > intended as it is still in development?
> > > >
> > > > --Miguel
>
> -- next part --
> An HTML attachment was scrubbed...
> URL:
> http://public.kitware.com/pipermail/cmake/attachments/20071119/94f4e9b6/att
>achment.html
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] QtDialog isn't installed?
> > People can change it all they want, it just won't get accepted upstream. > >I don't want to be forced to accept a license that I don't agree > > with. BTW, qt itself has the same sort of license. Trolltech does not > > accept changes from the community other than small bug fixes. This is > > so they can maintain the dual license that they have. I don't think > > there are linux distros that have stopped distribution of Qt are there? > > Stopping distribution of Qt isn't the issue. Stopping distribution of > semi-proprietary apps that use a Qt commercial license is the issue. > I'm looking around to see if there have been any flaps over this. > Meanwhile, here's their license overview. > http://trolltech.com/products/qt/licenses/licensing Its not a semi-proprietary app. The use of Qt with a commercial license allows the license holder to license they code they develop with any license they choose. The code in CMake/Source/QtDialog/ says it has a BSD license. Using open source Qt (GPL) means the code developed is GPL as well. Seems to me its just an extra step to give greater freedom than the GPL gives. There is no open source license that gives the freedom of forcing changes upstream :) Clint ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] QtDialog isn't installed?
On Tuesday 20 November 2007 10:45:56 am Mike Jackson wrote: > On Nov 20, 2007 12:34 PM, Brandon Van Every <[EMAIL PROTECTED]> wrote: > > On Nov 20, 2007 11:18 AM, Brandon Van Every <[EMAIL PROTECTED]> wrote: > > > On Nov 20, 2007 8:36 AM, Bill Hoffman <[EMAIL PROTECTED]> wrote: > > > > Hendrik Sattler wrote: > > > > >> Anyway, the GPL stuff still stands. > > > > > > > > > > Why don't you make the Qt dialog source GPL, then? > > > > > With those restrictions, some Linux distributions will either strip > > > > > the Qt dialog from the source or move whole cmake to an unofficial > > > > > repository. Allowing everyone to change the source code (and > > > > > distribute the result) is greatly preferred. > > > > > > > > People can change it all they want, it just won't get accepted > > > > upstream. I don't want to be forced to accept a license that I don't > > > > agree with. BTW, qt itself has the same sort of license. Trolltech > > > > does not accept changes from the community other than small bug > > > > fixes. This is so they can maintain the dual license that they have. > > > > I don't think there are linux distros that have stopped distribution > > > > of Qt are there? > > > > > > Stopping distribution of Qt isn't the issue. Stopping distribution of > > > semi-proprietary apps that use a Qt commercial license is the issue. > > > I'm looking around to see if there have been any flaps over this. > > > Meanwhile, here's their license overview. > > > http://trolltech.com/products/qt/licenses/licensing > > > > I'm perusing the Debian Free Software Guidelines. > > http://www.debian.org/doc/debian-policy/ch-archive.html#s-dfsg > > IANAL, nor am I a Debian archivist. But it looks like distributing > > QtDialog without dual licensing it under the GPL is in violation of > > the DFSG. "You could link this code if you bought a commercial > > license from Qt" doesn't fit the wording of the DFSG, nor probably the > > sensibility of the people who enforce it. > > > > Bill, I'd like to point out the potential negative consequences of > > taking a hard "I like Qt but I don't like the GPL" stance. It could > > create the impression that CMake is "bad and non-free" in the Linux > > world, where no such impression previously exists. I wouldn't risk > > doing it and seeing if anyone enforces. Once an enforcement happens, > > it will take forever for CMake to recover the damage to its > > reputation. Religious issues over licensing tend to have snowball / > > Slashdot effects; you can expect noise. Especially from the Autoconf > > crowd who will be granted lotsa ammo from such a flap. > > > > Respectfully, I suggest you dual license it or don't include it at > > all. It's not worth the risk. > > > > > > > > Cheers, > > Brandon Van Every > > Um.. How does ParaView 3 work then? It is built against Qt and > distributed as opensource? I get the impression Brandon thinks the QtDialog code is proprietary. Brandon, what license are you attributing the QtDialog code with? Its BSD licensed, like ParaView is. Clint ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindQt3.cmake bug - does not recognize uic
On Tuesday 27 November 2007 8:21:38 am Anka Kochanowska wrote:
> Hi!
> I am using Qt3 (3.3.3)
> In my CMakeList.txt I have conditionals:
>
> IF(QT_WRAP_UI)
> QT_WRAP_UI( Basic IGNS_BASIC_HDR IGNS_BASIC_SRC ${IGNS_BASIC_GUI_SRC} )
> ENDIF(QT_WRAP_UI)
>
> This used to work still in CMake 2.4 patch 3. Since themn, the
> FindQt3.cmake has been changed and it does not
> recognize uic.
>
>
> There is a problem with the following code:
>
> EXEC_PROGRAM(${QT_UIC_EXECUTABLE} ARGS "-version" OUTPUT_VARIABLE
> QTVERSION_UI)
>
> in my case QTVERSION_UI is:User Interface Compiler for Qt version
> 3.3.3
>
> The following test:
> SET(_QT_UIC_VERSION_3 FALSE)
> IF("${QTVERSION_UIC}" MATCHES ".* 3..*")
> SET(_QT_UIC_VERSION_3 TRUE)
> ENDIF("${QTVERSION_UIC}" MATCHES ".* 3..*")
>
> sets QT_UIC_VERSION_3 to FALSE
>
> which causes the
> SET(QT_WRAP_UI FALSE)
> IF (QT_UIC_EXECUTABLE)
> IF(_QT_UIC_VERSION_3)
> SET ( QT_WRAP_UI TRUE)
> ENDIF(_QT_UIC_VERSION_3)
> ENDIF (QT_UIC_EXECUTABLE)
>
> returning QT_WRAP_UI as FALSE
>
> I do not know how to set the regex in order to find 3 in the version
> return by uic. I tried differnt things and miserably failed.
>
> Could anyone help, please?
>
> I have seen quite few postings about QT_WRAP_UI failure and the
> suggestions were either to drop the condition or to manually run uic
I'm unable to reproduce this. Do you have a simple CMakeLists.txt file that
you can reproduce this with?
I'm also curious why you conditionally run uic. Wouldn't your project fail to
build without that? Do you really want IF(QT_FOUND) instead?
Clint
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch to FindQt4.cmake for supporting moc compiler options
On Saturday 24 November 2007 3:23:16 pm Miguel A. Figueroa-Villanueva wrote:
> Hello,
>
> I would like to propose the following patch or something similar to
> add support for moc compiler options. Currently, one can do the
> following:
>
> SET(moc-sources foo.h bar.h)
> QT4_WRAP_CPP(sources ${moc-sources})
>
> With the attached patch one could pass also options to be invoked with
> each moc-source:
>
> QT4_WRAP_CPP(sources ${moc-sources} OPTIONS -DMYDEF)
>
> The current approach is a simplified one to support the following syntax:
>
> QT4_WRAP_CPP( [OPTIONS opt1 opt2 ...])
>
> This could also be applied to QT4_WRAP_UI(...).
>
> --Miguel
I'm curious what the convention is for adding arguments to custom commands in
macros.
To compare, I see the FindSWIG.cmake/UseSWIG.cmake allow setting the
CMAKE_SWIG_FLAGS variable. The advantage of that is that it applies to all
calls of the macro.
Clint
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindQt3.cmake bug - does not recognize uic
On Tuesday 27 November 2007 10:52:55 am Anka Kochanowska wrote:
> Thanks for answering.
> Our application is built on different systems. Some of them have Qt3 and
> Qt4, some have not been properly installed, so having the condition
> would be helpful to diagnose the problem.
> FindQt3.cmake fails on Ubuntu, Debian and Mandrake. So we comment out
> the condition, but ...
> Also, there is no problem with moc and it is treated pretty much the
> same way as uic.
> What is your system?
I tried it on Fedora w/ CMake CVS.
uic -version gives me
"User Interface Compiler for Qt version 3.3.8"
What if you change the regex to this?
IF("${QTVERSION_UIC}" MATCHES ".* 3\\..*")
And did you check that the QT_UIC_EXECUTABLE in your CMakeCache.txt file is
indeed a Qt3's uic (now that you mention some are not installed properly)?
Clint
>
> Anka
>
> [EMAIL PROTECTED] wrote:
> >On Tuesday 27 November 2007 8:21:38 am Anka Kochanowska wrote:
> >>Hi!
> >>I am using Qt3 (3.3.3)
> >>In my CMakeList.txt I have conditionals:
> >>
> >>IF(QT_WRAP_UI)
> >> QT_WRAP_UI( Basic IGNS_BASIC_HDR IGNS_BASIC_SRC ${IGNS_BASIC_GUI_SRC} )
> >>ENDIF(QT_WRAP_UI)
> >>
> >>This used to work still in CMake 2.4 patch 3. Since themn, the
> >>FindQt3.cmake has been changed and it does not
> >>recognize uic.
> >>
> >>
> >>There is a problem with the following code:
> >>
> >>EXEC_PROGRAM(${QT_UIC_EXECUTABLE} ARGS "-version" OUTPUT_VARIABLE
> >>QTVERSION_UI)
> >>
> >>in my case QTVERSION_UI is:User Interface Compiler for Qt version
> >>3.3.3
> >>
> >>The following test:
> >>SET(_QT_UIC_VERSION_3 FALSE)
> >>IF("${QTVERSION_UIC}" MATCHES ".* 3..*")
> >> SET(_QT_UIC_VERSION_3 TRUE)
> >>ENDIF("${QTVERSION_UIC}" MATCHES ".* 3..*")
> >>
> >>sets QT_UIC_VERSION_3 to FALSE
> >>
> >>which causes the
> >>SET(QT_WRAP_UI FALSE)
> >>IF (QT_UIC_EXECUTABLE)
> >> IF(_QT_UIC_VERSION_3)
> >>SET ( QT_WRAP_UI TRUE)
> >> ENDIF(_QT_UIC_VERSION_3)
> >>ENDIF (QT_UIC_EXECUTABLE)
> >>
> >>returning QT_WRAP_UI as FALSE
> >>
> >>I do not know how to set the regex in order to find 3 in the version
> >>return by uic. I tried differnt things and miserably failed.
> >>
> >>Could anyone help, please?
> >>
> >>I have seen quite few postings about QT_WRAP_UI failure and the
> >>suggestions were either to drop the condition or to manually run uic
> >
> >I'm unable to reproduce this. Do you have a simple CMakeLists.txt file
> > that you can reproduce this with?
> >
> >I'm also curious why you conditionally run uic. Wouldn't your project
> > fail to build without that? Do you really want IF(QT_FOUND) instead?
> >
> >Clint
>
> ___
> CMake mailing list
> CMake@cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cross compiling
Acoording to that link you gave, a Visual Studio project file can be created from inf and mmp files. Can you get CMake to generate an equivalent Visual Studio project file? Clint On Friday 30 November 2007 1:02:42 pm Jesse Corrington wrote: > It seems there is some confusion over the symbian build files. If you are > interested, take a look at this article on building a simple hello world > app, which talks about the inf and mmp files. > > http://newlc.com/Getting-Started-with-Symbian.html > > > Jesse > > > On Nov 30, 2007 11:43 AM, Jesse Corrington <[EMAIL PROTECTED]> > > wrote: > > I'm pretty sure to build any symbian app you need an inf and mmp file. > > These have nothing to do with the eclipse plugin, but It is able to > > import them, so you need these files whether you are working in an IDE or > > building from the command line. The files are extremely simple, at least > > the ones we use. They are pretty close to just a flat list of files, > > because it uses all of the symbian default compiler flags and such. I > > can't get the CMake source at work right now, because our firewall is > > being stupid, but I am going to grab it this weekend and start having a > > look on Monday. I was planning to work from the makefile generator, since > > this will be similar to that. > > > > On Nov 30, 2007 12:55 AM, Torsten Martinsen <[EMAIL PROTECTED]> wrote: > > > The CVS version does, yes. > > > > > > -- > > > *From:* [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] *On Behalf Of *Josef > > > Karthauser > > > *Sent:* 30 November 2007 09:54 > > > *To:* Jesse Corrington; Salvatore Iovene > > > *Cc:* cmake@cmake.org; [EMAIL PROTECTED] > > > *Subject:* RE: [CMake] cross compiling > > > > > > Did I miss something? Does cmake support cross compiling now? > > > > > > -- > > > This e-mail and any files sent with it contain information that may be > > > privileged or confidential and is the property of the GateHouse Group. > > > This information is intended solely for the person to whom it is > > > addressed. If you are not the intended recipient, you are not > > > authorized to read, print, retain, copy, disseminate, distribute, or > > > use the message or any part thereof. If you have received this e-mail > > > in error, please notify the sender immediately, and delete all copies > > > of this message. In accordance with GateHouse Security Policy, e-mails > > > sent or received may be monitored. > > > > > > ___ > > > CMake mailing list > > > CMake@cmake.org > > > http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.4.8 RC 4
Can this be fixed for 2.4.8? It looks like it was already fixed for 2.6, but I couldn't find a bug report for it. = ADD_LIBRARY(A a.c) ADD_LIBRARY(Ad a.c) ADD_LIBRARY(B b.c) TARGET_LINK_LIBRARIES(B debug Ad optimized A) # if building shared libs, cmake correctly links B with -lAd OR -lA ADD_EXECUTABLE(C c.c) TARGET_LINK_LIBRARIES(C B) # cmake incorrectly links C with -lB -lAd -lA if build type is Debug === Clint On Wednesday 05 December 2007 3:13:39 pm Bill Hoffman wrote: > I have a beta release for 2.4.8 ready for cmake. This will be the last > release of the 2.4.X branch. The next release will be 2.6.0. So, > please make sure you test it if you are interested in a 2.4.8. Send any > issues to me or the cmake list. Thanks. > > The files can be found here: > > http://www.cmake.org/files/v2.4/*RC-4* > > > The changes from 2.4.7 are as follows: > > Changes in CMake 2.4.8 RC 4 > * fix for cpack and messing up PATH with NSIS > Changes in CMake 2.4.8 RC 3 > * fix for bug 5363: GET_TARGET_PROPERTY(... DEBUG_LOCATION) >returns value containing $(OutDir) > * Better error from ctest if nightly time not set > * Fix for exception handling flags in VS 2003 and up > * Avoid relinking exclude-from-all directory targets before install > Changes in CMake 2.4.8 RC 2 > * fix for bug 5590 relative paths in windows not working across drives > * fix warning/error with TAR_VERBOSE flag > Changes in CMake 2.4.8 RC 1 > * Fix for kde4-config location > * Fix for self extracting .sh files on solaris > * Remove KDE3_ENABLE_FINAL (did not work) > * KDE3 fix for 64 bit location of plugins > * mark PYTHON_EXECUTABLE as advanced > * Fix for version numbers on NetBSD > * Add more search directories (install prefix and cmake location) > * include WindowsPaths in Windows.cmake not just Windows-cl.cmake > * documentation fix for file, find_package, try_run > * add IS_ABSOLUTE to if > * INSTALL() everything which doesn't have a COMPONENT set, is assigned >to the COMPONENT "Unspecified" > * make #cmakedefine output match autoconf when undefined > * document cmake remove -f > * document order of -D and -P > * add support for DragonFly and GNU hurd > * fix for fortran depends doing too many scans > ___ > CMake mailing list > CMake@cmake.org > http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.4.8 RC 4
A co-worker sees it on his Windows box (VS 7.1), but I don't on mine (VS 8). So I don't know how to trigger it on Windows. But I see it consistent for me on Linux, both with that simple example and ParaView. Of course, I don't see the msvcrt(d) link warnings. Clint On Tuesday 11 December 2007 1:53:36 pm David Cole wrote: > It's something more than just this simple example... I've tried it with > CMake 2.4.5, 2.4.7 and today's CVS CMake and it does not happen on my > machine. (The Debug C always properly links to Ad only, not also to A...) > > I am using VS 2005 standard edition. > > The problem was occurring on the ParaView3 dashboards (until I masked it > out by mucking with CXX_FLAGS last Friday) on morva and minastirith > dashboards. Here's an example: > http://www.paraview.org/ParaView3/Testing/Sites/morva.kitware/Win32-vs8/200 >71207-0100-Nightly/BuildWarning.html > > morva is using CMake 2.4.5 and VS8 Professional edition, minastirith is > using CMake 2.4.7 and VS8 Standard edition. > > Any other clues about what additional steps / settings might be required to > trigger this error condition? > > On 12/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Can this be fixed for 2.4.8? It looks like it was already fixed for 2.6, > > but > > I couldn't find a bug report for it. > > > > = > > ADD_LIBRARY(A a.c) > > ADD_LIBRARY(Ad a.c) > > > > ADD_LIBRARY(B b.c) > > TARGET_LINK_LIBRARIES(B debug Ad optimized A) > > # if building shared libs, cmake correctly links B with -lAd OR -lA > > > > ADD_EXECUTABLE(C c.c) > > TARGET_LINK_LIBRARIES(C B) > > # cmake incorrectly links C with -lB -lAd -lA if build type is Debug > > === > > > > Clint > > > > On Wednesday 05 December 2007 3:13:39 pm Bill Hoffman wrote: > > > I have a beta release for 2.4.8 ready for cmake. This will be the last > > > release of the 2.4.X branch. The next release will be 2.6.0. So, > > > please make sure you test it if you are interested in a 2.4.8. Send > > > any issues to me or the cmake list. Thanks. > > > > > > The files can be found here: > > > > > > http://www.cmake.org/files/v2.4/*RC-4* > > > > > > > > > The changes from 2.4.7 are as follows: > > > > > > Changes in CMake 2.4.8 RC 4 > > > * fix for cpack and messing up PATH with NSIS > > > Changes in CMake 2.4.8 RC 3 > > > * fix for bug 5363: GET_TARGET_PROPERTY(... DEBUG_LOCATION) > > >returns value containing $(OutDir) > > > * Better error from ctest if nightly time not set > > > * Fix for exception handling flags in VS 2003 and up > > > * Avoid relinking exclude-from-all directory targets before install > > > Changes in CMake 2.4.8 RC 2 > > > * fix for bug 5590 relative paths in windows not working across drives > > > * fix warning/error with TAR_VERBOSE flag > > > Changes in CMake 2.4.8 RC 1 > > > * Fix for kde4-config location > > > * Fix for self extracting .sh files on solaris > > > * Remove KDE3_ENABLE_FINAL (did not work) > > > * KDE3 fix for 64 bit location of plugins > > > * mark PYTHON_EXECUTABLE as advanced > > > * Fix for version numbers on NetBSD > > > * Add more search directories (install prefix and cmake location) > > > * include WindowsPaths in Windows.cmake not just Windows-cl.cmake > > > * documentation fix for file, find_package, try_run > > > * add IS_ABSOLUTE to if > > > * INSTALL() everything which doesn't have a COMPONENT set, is assigned > > >to the COMPONENT "Unspecified" > > > * make #cmakedefine output match autoconf when undefined > > > * document cmake remove -f > > > * document order of -D and -P > > > * add support for DragonFly and GNU hurd > > > * fix for fortran depends doing too many scans > > > ___ > > > CMake mailing list > > > CMake@cmake.org > > > http://www.cmake.org/mailman/listinfo/cmake > > > > ___ > > CMake mailing list > > CMake@cmake.org > > http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6 - Runtime Error on OS X (10.4.11 Intel)
On Monday 14 January 2008 10:20:18 am 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.
Mike, did you change your copy of the code? QtDialog should be looking
for /Users/Shared/Toolkits/CMake-ICC/bin/cmake
instead of
/Users/Shared/Toolkits/CMake-ICC/bin/QtDialog.app/Contents/MacOS/cmake
QCMake.cxx has
#elif defined(Q_OS_MAC)
appDir.cd("../../../");
this->CMakeExecutable = appDir.filePath("cmake");
...
to find cmake outside the bundle.
Clint
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Help:Using CMake with Eclipse
Can you send us the CMakeCache.txt file you get after that run? And what's your version of CMake? Clint On Tuesday 15 January 2008 3:14:11 pm Yang, Y. wrote: > Hi, Eric > > I use vista. When I launch Eclipse from terminal. The following are output > when using external tool run CMake. > > > -- Check for working C compiler: cl > -- Check for working C compiler: cl -- works > -- Check size of void* > -- Check size of void* - done > -- Check for working CXX compiler: cl > -- Check for working CXX compiler: cl -- works > -- Looking for Q_WS_X11 > -- Looking for Q_WS_X11 - not found. > -- Looking for Q_WS_MAC > -- Looking for Q_WS_MAC - not found. > -- Looking for Q_WS_WIN > -- Looking for Q_WS_WIN - found > CMake Error: Could NOT find QtCore. Check > D:/eclipse/workspace/sdf4/build/CMakeFiles/CMakeError.log for more details. > -- Configuring done > > It's really strange. > > Best regards > Yang > > -Original Message- > From: Eric Noulard [mailto:[EMAIL PROTECTED] > Sent: 2008-1-14 (星期一) 21:56 > To: Yang, Y. > Cc: CMake ML > Subject: Re: [CMake] Help:Using CMake with Eclipse > > 2008/1/13, Yang, Y. <[EMAIL PROTECTED]>: > > Thanks. cmake can find qmake when use terminal. > > Then as Alex suggested this should be an environment problem. > > Could you launch Eclipse from the very same terminal > you succeed to run CMake from and retry ? > > What is your platform? > Linux? > Windows? > > What version of CMake and Eclipse do you use? > > > So maybe the best way is using eclipse as an Editor. > > I can assure you you may do more than that _CURRENTLY_. > > > But I hope in the futher, the CMake could be perfectly incorporated into > > the eclipse. It is reall a good tool. > > > > Thanks for you help. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Help:Using CMake with Eclipse
From what I see, things look fine.
Does C:\Qt\4.3.3\lib\QtCore4.lib or C:\Qt\4.3.3\lib\QtCored4.lib even exist?
Or are you trying to do something like using a gcc build of Qt that has
libQtCore4.a with a Microsoft compiler?
Clint
On Tuesday 15 January 2008 3:35:06 pm Yang, Y. wrote:
> I use CMake 2.4.7. The attachment is CMakeCache.txt
>
> CMakeError.log:
>
> Determining if the Q_WS_X11 exist failed with the following output:
>
> File
> D:/eclipse/workspace/sdf4/build/CMakeFiles/CMakeTmp/CheckSymbolExists.c: /*
> */
> #include
>
> void cmakeRequireSymbol(int dummy,...){(void)dummy;}
> int main()
> {
> #ifndef Q_WS_X11
> cmakeRequireSymbol(0,&Q_WS_X11);
> #endif
> return 0;
> }
>
> Determining if the Q_WS_MAC exist failed with the following output:
>
> File
> D:/eclipse/workspace/sdf4/build/CMakeFiles/CMakeTmp/CheckSymbolExists.c: /*
> */
> #include
>
> void cmakeRequireSymbol(int dummy,...){(void)dummy;}
> int main()
> {
> #ifndef Q_WS_MAC
> cmakeRequireSymbol(0,&Q_WS_MAC);
> #endif
> return 0;
> }
>
> ***
>**
>
> CMakeOutput:
>
> The system is: Windows - 6.0 - x86
> Determining if the C compiler works passed with the following output:
>
>
> Determining size of void* passed with the following output:
>
>
> Determining if the CXX compiler works passed with the following output:
>
>
> Determining if the Q_WS_WIN exist passed with the following output:
>
> File
> D:/eclipse/workspace/sdf4/build/CMakeFiles/CMakeTmp/CheckSymbolExists.c: /*
> */
> #include
>
> void cmakeRequireSymbol(int dummy,...){(void)dummy;}
> int main()
> {
> #ifndef Q_WS_WIN
> cmakeRequireSymbol(0,&Q_WS_WIN);
> #endif
> return 0;
> }
>
>
> ***
>*8
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: 2008-1-15 (星期二) 23:28
> To: cmake@cmake.org
> Cc: Yang, Y.
> Subject: Re: [CMake] Help:Using CMake with Eclipse
>
>
> Can you send us the CMakeCache.txt file you get after that run?
> And what's your version of CMake?
>
> Clint
>
> On Tuesday 15 January 2008 3:14:11 pm Yang, Y. wrote:
> > Hi, Eric
> >
> > I use vista. When I launch Eclipse from terminal. The following are
> > output when using external tool run CMake.
> >
> >
> > -- Check for working C compiler: cl
> > -- Check for working C compiler: cl -- works
> > -- Check size of void*
> > -- Check size of void* - done
> > -- Check for working CXX compiler: cl
> > -- Check for working CXX compiler: cl -- works
> > -- Looking for Q_WS_X11
> > -- Looking for Q_WS_X11 - not found.
> > -- Looking for Q_WS_MAC
> > -- Looking for Q_WS_MAC - not found.
> > -- Looking for Q_WS_WIN
> > -- Looking for Q_WS_WIN - found
> > CMake Error: Could NOT find QtCore. Check
> > D:/eclipse/workspace/sdf4/build/CMakeFiles/CMakeError.log for more
> > details. -- Configuring done
> >
> > It's really strange.
> >
> > Best regards
> > Yang
> >
> > -Original Message-
> > From: Eric Noulard [mailto:[EMAIL PROTECTED]
> > Sent: 2008-1-14 (星期一) 21:56
> > To: Yang, Y.
> > Cc: CMake ML
> > Subject: Re: [CMake] Help:Using CMake with Eclipse
> >
> > 2008/1/13, Yang, Y. <[EMAIL PROTECTED]>:
> > > Thanks. cmake can find qmake when use terminal.
> >
> > Then as Alex suggested this should be an environment problem.
> >
> > Could you launch Eclipse from the very same terminal
> > you succeed to run CMake from and retry ?
> >
> > What is your platform?
> > Linux?
> > Windows?
> >
> > What version of CMake and Eclipse do you use?
> >
> > > So maybe the best way is using eclipse as an Editor.
> >
> > I can assure you you may do more than that _CURRENTLY_.
> >
> > > But I hope in the futher, the CMake could be perfectly incorporated
> > > into the eclipse. It is reall a good tool.
> > >
> > > Thanks for you help.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] My dammed problem with OSX and Qt
On Wednesday 16 January 2008 11:05:04 am Leopold Palomo-Avellaneda wrote: > > Linking CXX shared library libpluginregistrodeiva.dylib > Undefined symbols: [snip] > "FichaBc::qt_metacall(QMetaObject::Call, int, void**)", referenced from: > vtable for RegistroIvain registroiva.o > RegistroIvaView::qt_metacall(QMetaObject::Call, int, void**)in > moc_registroivaview.o Unresolved vtables in Qt code usually means you forgot to run moc on the header file and include it in the build. If that's it, it can be done by the QT4_WRAP_CPP macro. On Linux, you might see that problem at run time with a crash. Clint ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindQt4 in 2.4.8 bug
On Friday 25 January 2008 10:58:19 am Fernando Cacciola wrote:
> Hi,
>
> I've been using 2.4.7 until this morning when I saw the 2.4.8 announcement
> and jumped right away to install it (silly me).
> I have some script that finds Qt4 but stopped working on 2.4.8.
> Tracing the problem in FindQt4.cmake I found this...
> There is one (at least one) SET command like this:
> SET( QT_INCLUDE_DIR ${qt4_include_dir} CACHE PATH "")
> which fails to actually set the value of QT_INCLUDE_DIR
> It works fine if DOCSTRING is prepended in front of "":
> SET( QT_INCLUDE_DIR ${qt4_include_dir} CACHE PATH DOCSTRING "")
> Is this a bug in FindQt4.cmake? ( was this differently in 2.4.7? )
> A bug in 2.4.8 ( DOCSTRING should not be needed? )
> A feature in 2.4.8 ? (is needed just now? )
>
Or perhaps ${qt4_include_dir} is empty, so it messes up the rest of the
arguments.
This is on a Mac, right? And is Qt configured with -no-framework?
Did it set QT_QTCORE_INCLUDE_DIR and QT_LIBRARY_DIR correctly?
Clint
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [Help] Build Qt Plugin with CMake
On Sunday 03 February 2008 12:18:12 pm Yang, Y. wrote:
> Hi All,
>
> when I try to build a plugin with my qt application on windows, I found
> that the dll build successfully, but when I launch my application it failed
> with a message that myplugin.dll is not a valid Qt plugin.
>
>
> The following file is my CMakeLists.txt. Is there anything wrong?
> **
> project(myplugin)
>
> set(myplugin_SRCS
> myplugin.cpp
> )
>
> set(myplugin_MOC_HDRS
> myplugin.h
> )
>
>
> include_directories(${QT_INCLUDES} ${CMAKE_CURRENT_BINARY_DIR}
> ${CMAKE_CURRENT_SOURCE_DIR} ${CMAKE_CURRENT_SOURCE_DIR}/../../core)
>
> add_definitions(${QT_DEFINITIONS})
> add_definitions(-DQT_PLUGIN)
> add_definitions(-DQT_SHARED)
> add_definitions(-DQT_NO_DEBUG)
-DQT_NO_DEBUG all the time means your plugin won't work with debug builds on
Windows.
Clint
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] ctest & ctrl-c
When running ctest, and I hit ctrl-c to stop it, is it supposed to kill the application being run by ctest? On Windows, I'm stale apps that I have to kill with the task manager that ctest didn't kill. Clint ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Qt 4.4 Phonon and WebKit
On Monday 11 February 2008 8:53:34 am StefanV wrote: > Hello List, > I've started using cmake some days ago to build a cpp-app using Qt4.4 > Technology Preview 1 on my Debian Sid host. I need to link against the > new Phonon-Lib, so I extended the standard CMake 2.4.8 Modules to be > able to link against the lib. I only tested Phonon, whose name may > change in future. I tried to test if the minor version is 4, but I > don't know if the position of the test (UseQt4.cmake) is right, as my > understanding of cmake is rather limited ATM. The Patches: > http://web1.v846.ncsrv.de/cmake/UseQt4.cmake_Qt4.4tp1.patch > http://web1.v846.ncsrv.de/cmake/FindQt4.cmake_Qt4.4tp1.patch > Thanks. You can track the status with this bug report. http://public.kitware.com/Bug/view.php?id=6316 Clint ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] FindPythonLibs.cmake
Anyone know why FindPythonLibs.cmake in CVS adds a custom target? In Visual Studio, it shows up as a project (__FindPythonLibsHelper) and it appears to do nothing. Clint ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] problem deploying 64 bit from VS 2005
Hi,
I've got this problem deploying 64 bit binaries from Visual Studio 2005
I've got this app
#include
int main()
{
printf("hello world\n");
}
==
And this CMakeLists.txt file ==
ADD_EXECUTABLE(testdeploy main.cpp)
INCLUDE(InstallRequiredSystemLibraries)
INSTALL(TARGETS testdeploy DESTINATION bin)
SET(CPACK_PACKAGE_EXECUTABLES "testdeploy" "TestDeploy")
INCLUDE(CPack)
=
I built it with Visual Studio 2005 (64 bit release binary on 64 bit vista, if
that matters) and built the PACKAGE project.
I took my .exe installer (nsis) and ran it on another clean vista install, and
it gives me the error
C:\Program Files\Project 0.1.1\bin\testdeploy.exe
The application has failed to start because its side-by-side
configuration is
incorrect. Please see the application event log for more detail.
The event log contains ===
Activation context generation failed for "C:\Program Files\Project
0.1.1\bin\testdeploy.exe".Error in manifest or policy file "C:\Program
Files\Project 0.1.1\bin\Microsoft.VC80.CRT.MANIFEST" on line 4. Component
identity found in manifest does not match the identity of the component
requested. Reference is
Microsoft.VC80.CRT,processorArchitecture="amd64",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.762".
Definition is
Microsoft.VC80.CRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.762".
Please use sxstrace.exe for detailed diagnosis.
That's not the same error I get when trying to deploy my real application, but
in this case, the error appears to be a 32 vs 64 bit issue.
When deploying my real application, I tried using sxstrace as the event log
suggested, but it gives me a bunch of stuff that I can't make sense of. So I
thought I'd try starting from the simplest app, and even that failed.
And I'm using CVS CMake as of yesterday.
Any ideas?
Clint
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] problem deploying 64 bit from VS 2005
I looked in InstallRequiredSystemLibraries.cmake, and it doesn't handle 64
bit. In other words, "x86" is hardcoded when I want "amd64" instead.
I'm trying some changes
Clint
On Friday 14 March 2008 2:17:48 pm David Cole wrote:
> Sounds like INCLUDE(InstallRequiredSystemLibraries) is not giving you the
> 64-bit dlls...
> Can you run dumpbin on one of the installed dlls to see if it's x86 or
> amd64??
>
> Just open a Visual Studio command prompt and type "dumpbin blah.dll" and
> send along the results...
>
> On 3/14/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I've got this problem deploying 64 bit binaries from Visual Studio
> > 2005
> >
> > I've got this app
> >
> > #include
> > int main()
> > {
> > printf("hello world\n");
> > }
> > ==
> >
> > And this CMakeLists.txt file ==
> >
> > ADD_EXECUTABLE(testdeploy main.cpp)
> > INCLUDE(InstallRequiredSystemLibraries)
> > INSTALL(TARGETS testdeploy DESTINATION bin)
> > SET(CPACK_PACKAGE_EXECUTABLES "testdeploy" "TestDeploy")
> > INCLUDE(CPack)
> > =
> >
> > I built it with Visual Studio 2005 (64 bit release binary on 64 bit
> > vista, if
> > that matters) and built the PACKAGE project.
> > I took my .exe installer (nsis) and ran it on another clean vista
> > install, and
> > it gives me the error
> >
> > C:\Program Files\Project 0.1.1\bin\testdeploy.exe
> > The application has failed to start because its side-by-side
> > configuration is
> > incorrect. Please see the application event log for more detail.
> >
> > The event log contains ===
> > Activation context generation failed for "C:\Program Files\Project
> > 0.1.1\bin\testdeploy.exe".Error in manifest or policy file "C:\Program
> > Files\Project 0.1.1\bin\Microsoft.VC80.CRT.MANIFEST" on line 4. Component
> > identity found in manifest does not match the identity of the component
> > requested. Reference is
> > Microsoft.VC80.CRT
> > ,processorArchitecture="amd64",publicKeyToken="1fc8b3b9a1e18e3b",type="wi
> >n32",version=" 8.0.50727.762".
> > Definition is
> > Microsoft.VC80.CRT
> > ,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win3
> >2",version=" 8.0.50727.762".
> > Please use sxstrace.exe for detailed diagnosis.
> >
> >
> > That's not the same error I get when trying to deploy my real
> > application, but
> > in this case, the error appears to be a 32 vs 64 bit issue.
> >
> > When deploying my real application, I tried using sxstrace as the event
> > log
> > suggested, but it gives me a bunch of stuff that I can't make sense
> > of. So I
> > thought I'd try starting from the simplest app, and even that failed.
> >
> > And I'm using CVS CMake as of yesterday.
> >
> > Any ideas?
> >
> > Clint
> > ___
> > CMake mailing list
> > CMake@cmake.org
> > http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Suppressing Windows console in Qt app
On Monday 24 March 2008 7:45:57 am Matthew Smith wrote: > Hi everyone, > > When I build my Qt 4 app (QTM) using CMake on Windows Vista and then run > it from a prompt, the prompt does not come back as it does with normal > Windows GUI apps; it behaves as if it's running a console-based > application. If you press Ctrl+C, it kills the program. If you run it > from Explorer, it opens a prompt window but doesn't give you a prompt, > and similarly you can kill QTM by closing the window. When I build > using qmake, I do not have this problem; it just gives me the prompt > back. Does anyone know how to fix this? > > Regards, > > Matt Smith Use WIN32 in your ADD_EXECUTABLE command. You can see http://www.cmake.org/HTML/CMake-2.4.html for more details. Clint ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Suppressing Windows console in Qt app
> If you are going to be building this as a cross platform application,
> then the following is useful:
>
>
> # Set some Win32 Specific Settings
> IF(WIN32)
> SET(GUI_TYPE WIN32)
> ENDIF(WIN32)
> # Set some Apple MacOS Specific settings
> IF (APPLE)
> SET(GUI_TYPE MACOSX_BUNDLE)
> ENDIF (APPLE)
>
> ADD_EXECUTABLE( MyApplication ${GUI_TYPE} ${PROJECT_SRCS} )
I usually do that a simpler way.
ADD_EXECUTABLE( MyApplication WIN32 MACOSX_BUNDLE ${PROJECT_SRCS} )
It doesn't break a Linux build to have WIN32 there.
Clint
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6 Gui App not picking up environment variables
On Friday 28 March 2008 9:57:32 am David Cole wrote: > You can launch it from a shell that has the env set : > open /Applications//cmake-gui.app > > Or follow the directions here to set env vars for all your GUI apps in Mac > OSX: > http://developer.apple.com/documentation/MacOSX/Conceptual/OSX_Technology_O >verview/CommandLine/chapter_950_section_4.html This one shows that the property editor can be used. http://developer.apple.com/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/EnvironmentVars.html Clint ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6.0 RC 10 ready for testing
Do you still have the problem if you delete your build_dir/Examples directory, re-run cmake, and rebuild? Perhaps you have some leftovers from a previous VTK configuration still stuck in your examples? Clint On Thursday 01 May 2008 2:02:31 pm Yves Starreveld wrote: > When building cvs VTK with qt4 on OSX.5.2: > > [ 99%] Generating ../VTKExamples > Internal cmake changing into directory: /Users/ystarrev/Development/ > vtkbin/Examples/All > CMake output == > Multiple versions of QT found please set DESIRED_QT_VERSION > Multiple versions of QT found please set DESIRED_QT_VERSION > Multiple versions of QT found please set DESIRED_QT_VERSION > CMake Warning (dev) at GUI/Qt/ImageViewer/CMakeLists.txt:28 > (ADD_EXECUTABLE): > Policy CMP0003 should be set before this line. Add code such as > > if(COMMAND cmake_policy) > cmake_policy(SET CMP0003 NEW) > endif(COMMAND cmake_policy) > > > > > Despite having DESIRED_QT_VERSION set to 4 in the main CMakeCache.txt > file. > > (qt4 built with -no-frameworks option) > > Yves > > On 1-May-08, at 1:48 PM, Bill Hoffman wrote: > > I am happy to announce that CMake 2.6.0 RC10 is ready for testing. > > You can find the source and binaries here: > > http://www.cmake.org/files/v2.6/ > > > > Please give it a try soon. I really mean it this time... I am going > > to release 2.6.0 soon. :) > > ___ > CMake mailing list > CMake@cmake.org > http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [Paraview] paraview CVS xcodebuild
On Thursday 08 May 2008 10:45:43 am Robert Maynard wrote: > What version of ParaView is this? CVS or 3.2? CVS ParaView (which is probably a bit bigger than 3.2) and I used CMake 2.6. Clint > > On the current CVS my Macbook with 2GB of ram will start compiling with > xcodebuild, but will fail 1 or 2 projects in. > > I was though able to compile ParaView with makefiles, and then force the > cmake to make xcode projects for plugins without problem. > > Clinton Stimpson wrote: > > I can build ParaView on a Macbook with 2 GB of Ram using Xcode 2.4 on > > Mac 10.4. > > The only setting I changed was to build shared libraries. > > Ram usage was about 750 MB through the whole process. > > > > Clint > > > > On May 7, 2008, at 4:52 PM, jonathan grimm wrote: > >> paraview CVS xcodebuild is no longer working. On a Mac Pro 16GB ram > >> with 10.5. I checked and xcodebuild is a 32 bit executable. > >> Makefiles work on the same machine. > >> Is there anything that can be done about this? The .xcodeproj is > >> only 14 MB. > >> > >> -- > >> Sometimes it's hard to tell the dancer from the dance - Corwin in CoC > >> ___ > >> CMake mailing list > >> CMake@cmake.org > >> http://www.cmake.org/mailman/listinfo/cmake > > > > ___ > > ParaView mailing list > > [EMAIL PROTECTED] > > http://www.paraview.org/mailman/listinfo/paraview ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Executable extension (MSVC)
On Wednesday 14 May 2008 11:05:43 am David Cole wrote: > No flags, just name the output file .com instead of .exe... Right. > > Still works with present day Visual Studio... Even Visual Studio has a tiny devenv.com which probably calls devenv.exe and keeps it attached to the console to see output in batch mode. Clint > > On Wed, May 14, 2008 at 1:00 PM, John Drescher <[EMAIL PROTECTED]> wrote: > > > What are the flags used in MSVC to create a .com file? > > > > I assume you need a very old version of msvc to support 16 bit > > compiles. Microsoft compilers have not supported this since version > > 4.X I believe which was more than 10 years ago. > > > > John > > ___ > > CMake mailing list > > CMake@cmake.org > > http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] QTCore Not Found:(
On Monday 19 May 2008 9:21:32 am Julien Valentin wrote: > Hello, I'm using QT 4.3.3 and cmake 2.4.7 since one year without having any > problem but recently I upgrade my configuration to cmake 2.6 and now I have > a Cmake error: QTGUI not found and QTCORE not found... I have test to build > vtk to test if the error come from me but it gaves me the sames messages. > Would someone can help me? Can you send me your CMakeCache.txt file from the vtk build? Clint ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [PATCH] FindQt4.cmake qt4_automoc improvements
On Monday 19 May 2008 12:46:04 pm Tanguy Krotoff wrote:
> On Mon, May 19, 2008 at 8:20 PM, Alexander Neundorf
>
> <[EMAIL PROTECTED]> wrote:
> > If you don't want that you don't have to use UseQt4.cmake and use
> > FindQt4.cmake directly.
> > There you have fine grained control over that.
>
> I want to use UseQt4.cmake since it defines important things:
> - QT_DEBUG/QT_NO_DEBUG
> - add ${QT_QTMAIN_LIBRARY} if under Windows
> - all the -DQT_GUI_LIB, -DQT_CORE_LIB...
> I was not using UseQt4.cmake until I encounter some issues under MinGW
> as QT_DEBUG/QT_NO_DEBUG were not defined.
> Probably QT_DEBUG/QT_NO_DEBUG should be moved to FindQt4.cmake as it
> is important.
>
> The only problem with UseQt4.cmake is the INCLUDE_DIRECTORIES() which
> increases compilation time.
Can you explain why?
Is it because you have dependent modules that you don't use directly, that
need to be turned on for linking?
In the past, I've thought of modifying UseQt4.cmake to partially turn on
dependent modules automatically (for linking), which would allow not having
as many include directories.
This would allow for behavior closer to what qmake does.
Thanks,
Clint
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [PATCH] FindQt4.cmake qt4_automoc improvements
On Monday 19 May 2008 12:46:04 pm Tanguy Krotoff wrote:
> On Mon, May 19, 2008 at 8:20 PM, Alexander Neundorf
>
> <[EMAIL PROTECTED]> wrote:
> > If you don't want that you don't have to use UseQt4.cmake and use
> > FindQt4.cmake directly.
> > There you have fine grained control over that.
>
> I want to use UseQt4.cmake since it defines important things:
> - QT_DEBUG/QT_NO_DEBUG
> - add ${QT_QTMAIN_LIBRARY} if under Windows
> - all the -DQT_GUI_LIB, -DQT_CORE_LIB...
> I was not using UseQt4.cmake until I encounter some issues under MinGW
> as QT_DEBUG/QT_NO_DEBUG were not defined.
> Probably QT_DEBUG/QT_NO_DEBUG should be moved to FindQt4.cmake as it
> is important.
>
> The only problem with UseQt4.cmake is the INCLUDE_DIRECTORIES() which
> increases compilation time.
UseQt4.cmake in CVS has been recently patched to reduce the number of include
directories specified in certain cases.
For example, if QT_USE_QTUITOOLS=1 but QT_USE_XML=0, the QtXml includes and
defines are no longer added. If you still want the includes, because you use
QtXml directly, you can set QT_USE_XML=1. qmake makes developer that
explicit too.
Hope that solves your problem.
Clint
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] QTCore Not Found:(
On Monday 19 May 2008 9:21:32 am Julien Valentin wrote: > Hello, I'm using QT 4.3.3 and cmake 2.4.7 since one year without having any > problem but recently I upgrade my configuration to cmake 2.6 and now I have > a Cmake error: QTGUI not found and QTCORE not found... I have test to build > vtk to test if the error come from me but it gaves me the sames messages. > Would someone can help me? Just to finish the thread, and for future reference. The problem was using precompiled open source Qt (built by mingw) with Visual Studio. Clint ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Compiler flags for Obj-C++ files only
On Wednesday 21 May 2008 1:08:40 pm Allan Odgaard wrote:
> I need to set a compiler flag for Obj-C++ files (-fobjc-call-cxx-
> cdtors).
>
> Setting it for C++ will give a warning from gcc when the source file
> type is C++ (instead of Obj-C++).
>
> Is there any way to set flags for only Obj-C++ files?
>
Does
set_source_files_properties( ${obj_Cpp_files} PROPERTIES
COMPILE_FLAGS "-fobjc-call-cxx-cdtors")
work?
I've done that kind of thing with mixed fortran & C projects before.
Clint
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [PATCH] FindQt4.cmake qt4_automoc improvements
On Tuesday 27 May 2008 9:53:34 am Tanguy Krotoff wrote:
> Again on the INCLUDE_DIRECTORIES(${QT_${module}_INCLUDE_DIR}) from
> UseQt4.cmake Since it is confirmed that Trolltech and kdelibs devs take
> care about the #include
Yes, Qt does take care with their public headers to let you do that.
But, it is interesting that most of the Qt examples don't follow this
convention.
There are 3 conventions in the Qt examples (from most common to least common):
1. #include
2. #include
3. #include
Both 1 and 2 require the include paths you're trying to get rid of.
>
> Will a patch like this would be OK?
>
> It simply add a variable set to ON by default.
> If OFF then UseQt4.cmake does not do
> INCLUDE_DIRECTORIES(${QT_${module}_INCLUDE_DIR})
If we do this, I'd rather have a variable initially unset. Then let you set
it to exclude the inlude paths.
>
> And maybe one day, this variable will be set to OFF by default...
I don't think we can ever make it the default.
I'm curious what the timings are with and without the include paths. Can you
give some data?
If I remember right, this thread started by talking about compile times.
Clint
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [PATCH] FindQt4.cmake qt4_automoc improvements
Your patch doesn't work with build systems that have configurations (Visual
Studio, XCode, etc..). Adding -DQT_DEBUG or -DQT_NO_DEBUG cannot rely on
CMAKE_BUILD_TYPE.
What's wrong with leaving it in UseQt4.cmake? In general, things work better
if you use UseQt4.cmake (not only because of QT_DEBUG/QT_NO_DEBUG).
Clint
On Thursday 29 May 2008 12:25:53 pm Tanguy Krotoff wrote:
> This thread contained another issue related to UseQt4.cmake and
> FindQt4.cmake:
>
> I wrote a bug report here http://public.kitware.com/Bug/view.php?id=7123
>
> >> If you don't want that you don't have to use UseQt4.cmake and use
> >> FindQt4.cmake directly.
> >> There you have fine grained control over that.
> >
> > I want to use UseQt4.cmake since it defines important things:
> > - QT_DEBUG/QT_NO_DEBUG
> > - add ${QT_QTMAIN_LIBRARY} if under Windows
> > - all the -DQT_GUI_LIB, -DQT_CORE_LIB...
> > I was not using UseQt4.cmake until I encounter some issues under MinGW
> > as QT_DEBUG/QT_NO_DEBUG were not defined.
> > Probably QT_DEBUG/QT_NO_DEBUG should be moved to FindQt4.cmake as it
> > is important.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [PATCH] FindQt4.cmake qt4_automoc improvements
On Thursday 29 May 2008 12:59:18 pm Tanguy Krotoff wrote: > On Thu, May 29, 2008 at 8:48 PM, <[EMAIL PROTECTED]> wrote: > > Your patch doesn't work with build systems that have configurations > > (Visual Studio, XCode, etc..). > > Oups... I never use Visual Studio and others. > > > What's wrong with leaving it in UseQt4.cmake? In general, things work > > better if you use UseQt4.cmake (not only because of > > QT_DEBUG/QT_NO_DEBUG). > > Then why separate UseQt4 and FindQt4? A finder (FindQt4.cmake) is simply supposed to just find things and isn't supposed to modify your compile environment. Qt requires a complicated enough environment to build in that a UseQt4.cmake helps set it up. It also allows you to set it up within a limited scope in case you have a mixed Qt and non-Qt project. Some Qt-only projects may not care about that separation. > For example, Phonon (I didn't wrote it ;) does not use UseQt4.cmake > and probably many other Qt apps do the same. Yes, I have seen that many projects don't use UseQt4.cmake. In that case, they have the extra work of setting up the compile environment. > > The bug that I got with QT_DEBUG/QT_NO_DEBUG not being defined is a > pretty hard one. Yes, it is a difficult one. It would be nice to be able to somehow put them into the QT_DEFINITIONS variable, but CMake doesn't support that. CMake 2.4.8 put them in CMakeCache.txt under CMAKE_CXX_FLAGS_ But, yesterday, another user brought up an issue that resulted from that. http://www.cmake.org/pipermail/cmake/2008-May/022023.html CMake 2.6 has a new SET_PROPERTY(...), which I think is a good fit. And this is what the current UseQt4.cmake uses. > I simply would like other devs not to spend time on such stupid > issues, so how can this be prevented? This stuff is better documented in 2.6 than it has ever been before. http://www.cmake.org/HTML/cmake-2.6.html#module:FindQt4 There were/are some other websites that docuemented or gave examples without using UseQt4.cmake, which may have led to more people not using it. But some people are getting it right. http://da-crystal.net/GCMS/blog/cmake-amp-qt4-modules/ Clint ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [PATCH] FindQt4.cmake qt4_automoc improvements
On Sunday 01 June 2008 3:02:11 pm Christian Ehrlicher wrote: > Alexander Neundorf schrieb: > > On Thursday 29 May 2008, Christian Ehrlicher wrote: > >> Tanguy Krotoff schrieb: > >>> On Thu, May 29, 2008 at 8:48 PM, <[EMAIL PROTECTED]> wrote: > >>> The bug that I got with QT_DEBUG/QT_NO_DEBUG not being defined is a > >>> pretty hard one. > >>> I simply would like other devs not to spend time on such stupid > >>> issues, so how can this be prevented? > >> > >> We hit this problem some time ago and fixed it locally. > >> FindQt4.cmake from kdelibs has a fix for this - I thought alex already > >> merged this back to FindQt4 from cmake. > > > > I try to merge partly from time to time, but the differences have become > > quite big, also because the one from cmake must be more general than the > > one from KDE (for KDE it's ok if FindQt4.cmake just supports the Qt > > versions we require, i.e. currently >= 4.3.0) > > So there are some things which will stay different. > > np, but the ndebug thing should be easy to merge, or? CMake's UseQt4.cmake had that fix more than a week before KDE's FindQt4.cmake, so it seems it got merged the other way. Clint ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Get Qt DLL paths for INSTALL
On Wednesday 18 June 2008 10:51:17 am Mike Arthur wrote:
> We can't static-link Qt into our application as we're relying on dynamic
> loading of plugins.
>
> As a result I want to install the necessary Qt*.dll files.
>
> Is there an easy (or not so easy) way of getting these files from
> ${QT_LIBRARIES} or something similar?
>
> Thanks in advance!
It would probably be easier to get them from QT_QT*_LIBRARY_RELEASE or
QT_QT*_LIBRARY_DEBUG variables, and replace the .lib extension with the .dll.
If you use QT_LIBRARIES, you've got extra work to separate the debug and
release libraries.
Clint
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Get Qt DLL paths for INSTALL
On Friday 20 June 2008 8:52:25 am Mike Arthur wrote: > On Wednesday 18 June 2008 21:19:33 you wrote: > > It would probably be easier to get them from QT_QT*_LIBRARY_RELEASE or > > QT_QT*_LIBRARY_DEBUG variables, and replace the .lib extension with the > > .dll. > > Thanks, I opted for this approach. > > Again, I think it would probably be worth having something in FindQt4 to > get the dll locations? To CMake people in general, Would it make sense to include macros in CMake that can be called to copy the Qt runtimes into an install/package? It seems people keep rolling their own. We have a script that installs the Microsoft runtimes, but I don't see much more beyond that. Clint ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Get Qt DLL paths for INSTALL
On Friday 20 June 2008 2:16:24 pm Bill Hoffman wrote: > [EMAIL PROTECTED] wrote: > > On Friday 20 June 2008 8:52:25 am Mike Arthur wrote: > >> On Wednesday 18 June 2008 21:19:33 you wrote: > >>> It would probably be easier to get them from QT_QT*_LIBRARY_RELEASE or > >>> QT_QT*_LIBRARY_DEBUG variables, and replace the .lib extension with the > >>> .dll. > >> > >> Thanks, I opted for this approach. > >> > >> Again, I think it would probably be worth having something in FindQt4 to > >> get the dll locations? > > > > To CMake people in general, > > > > Would it make sense to include macros in CMake that can be called to copy > > the Qt runtimes into an install/package? It seems people keep rolling > > their own. We have a script that installs the Microsoft runtimes, but I > > don't see much more beyond that. > > Dave Cole is working on a general purpose way to get depends for a > project. It is in Modules/GetPrerequisites.cmake. In the source tree > of CMake, there is also: > > QtDialog/CMakeIngestOSXBundleLibraries.cmake > > That is a previous version of the same thing althoug specific for the > Mac, as we just link static cmake for windows right now. That should > work with Qt or any other libraries an application might use. > > -Bill That's nice. There's possibly other file(s) or binaries (executables and/or plugins) that need to be included that aren't linked directly into the Qt based application. How could that that be handled? Though, it sounds like the GetPrerequisites.cmake would still do most of the work. Clint ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Out-of-source build with QT_WRAP_UI
I've written comments in between...
On Wednesday 25 June 2008 2:28:17 am Roy van Pelt wrote:
> Dear all,
>
> I'm trying to create the following situation, but so far I did not
> manage to do so with the examples I found on the Internet.
>
> I have:
>
> build_linux\
> CMakeLists.txt
> src
> ui
> mainWindow.ui
> main.cxx
> main.h
> CMakeLists.cxx
>
> The root CMakeLists uses SUBDIR to run the CMakeLists for my Linux
> build. Now I want QT_WRAP_UI to generate the necessary header and source
> files. By default however it places them in the build directory?!
>
> How can I get the generated files to be generated in the ui directory?
>
> I include the current CMakeLists.txt for the linux build below.
>
> Thanks in advance.
>
> #==
>== SET(EXECUTABLE_NAME bmrvis)
>
> SET(SRC_DIR ../src)
> SET(GUI_DIR ../src/ui)
>
> #--
>- # Find Qt package library and include files.
> #--
>- SET(DESIRED_QT_VERSION ${VTK_DESIRED_QT_VERSION} CACHE FILEPATH "")
Why set the DESIRED_QT_VERSION? You probably want to remove that.
>
> FIND_PACKAGE(Qt4 REQUIRED)
> IF(QT_USE_FILE)
> INCLUDE(${QT_USE_FILE})
> ELSE(QT_USE_FILE)
> SET(QT_LIBRARIES ${QT_QT_LIBRARY})
This else case doesn't make sense when using Qt4, as it always has a use file,
and QT_QT_LIBRARY is undefined.
> ENDIF(QT_USE_FILE)
>
> #--
>- # Build list of class files.
> #--
>- SET(CLASSES
> main
> )
>
> FOREACH(class ${CLASSES})
> SET(SOURCES ${SRC_DIR}/${class}.cxx ${SRC_DIR}/${class}.h)
> ENDFOREACH(class)
>
> #--
>- # Build list of ui files.
> #--
>- SET(GUI_FILES
> QMainWindow
> )
>
> FOREACH(guifile ${GUI_FILES})
> SET(GUI ${GUI_DIR}/${guifile}.ui)
> ENDFOREACH(guifile)
>
> IF (QT_WRAP_UI)
> QT_WRAP_UI(bmrvis_gui_lib GUI_HEADERS GUI_SOURCES ${GUI} )
> ENDIF (QT_WRAP_UI)
When using Qt4 it should instead be
QT4_WRAP_UI(GUI_HEADERS ${GUI} )
>
> #--
>- # Specify that given list of source files is part of final library.
> #--
>- ADD_EXECUTABLE(${EXECUTABLE_NAME} ${SOURCES} ${GUI_SOURCES} )
You need to add ${GUI_HEADERS} and remove ${GUI_SOURCES}
Clint
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] MSVC Qt Integration
Is it not possible for Trolltech to make their Qt integration work with
project files that they didn't generate?
Last time I tried, it seemed more things didn't work than I would have
expected.
Clint
On Thursday 10 July 2008 9:48:43 am Thomas Burdick wrote:
> I'm trying to get Qt integration to work in visual studio using cmake to
> generate the project and solution files.
>
> So far I've gotten part of the puzzle together using set_target_properties
> as described in the documentation to set the VS_KEYWORD.
>
> There is another piece though, in the solution file itself in Qt
> integration based projects there is something like GlobalSection(Qt) as
> shown below. How would I go about doing this in CMake so I can once again
> have Qt integration working?
>
> Microsoft Visual Studio Solution File, Format Version 9.00
> # Visual Studio 2005
> Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "test",
> "test\test.vcproj", "{6D8CFDDB-B43B-4DA1-935B-85406F4867FC}"
> GlobalSection(Qt) = preSolution
> Integration = True
> EndGlobalSection
> EndProject
> Global
> GlobalSection(SolutionConfigurationPlatforms) = preSolution
> Debug|Win32 = Debug|Win32
> Release|Win32 = Release|Win32
> EndGlobalSection
> GlobalSection(ProjectConfigurationPlatforms) = postSolution
> {6D8CFDDB-B43B-4DA1-935B-85406F4867FC}.Debug|Win32.ActiveCfg =
> Debug|Win32
> {6D8CFDDB-B43B-4DA1-935B-85406F4867FC}.Debug|Win32.Build.0 =
> Debug|Win32
> {6D8CFDDB-B43B-4DA1-935B-85406F4867FC}.Release|Win32.ActiveCfg =
> Release|Win32
> {6D8CFDDB-B43B-4DA1-935B-85406F4867FC}.Release|Win32.Build.0 =
> Release|Win32
> EndGlobalSection
> GlobalSection(SolutionProperties) = preSolution
> HideSolutionNode = FALSE
> EndGlobalSection
> EndGlobal
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] static libs and more
I also noticed that dumpbin /exports mylib.lib printed symbols out if it was an import library, but didn't if it was a static library. Clint On Thursday 17 July 2008 3:03:02 pm David Cole wrote: > If you do...: > dumpbin /symbols mylib.lib > > ...then: > The output will contain "_IMPORT_DESCRIPTOR" if the .lib is an import > library for a .dll file. > It will (most likely) not contain this output if it is a static .lib file. > > It's a heuristic as I'm pretty sure the static .lib file will contain that > output if you have, for example, a function named "PRINT_IMPORT_DESCRIPTOR" > in your library... But the absence of that string tells you that it is > *not* an import library for a .dll. > > You could easily write a CMake macro that calls dumpbin with > EXECUTE_PROCESS and capture its output into a variable and analyze it. > > (dumpbin.exe is usually available in the "VC\bin" directory of a Visual > Studio installation... easily accessible from a VC command prompt...) > > > HTH, > David > > On Thu, Jul 17, 2008 at 4:09 PM, Philip Lowman <[EMAIL PROTECTED]> wrote: > > .. Original Message ... > > On Thu, 17 Jul 2008 22:10:11 +0400 "Yuri Timenkov" > > > > <[EMAIL PROTECTED]> wrote: > > >On Thursday 17 July 2008 23:00:15 Alin M Elena wrote: > > >The main problem AFAIK for VS is that static and dynamic libraries are > > >indistinguishable by extension. They both have a .lib one. And you don't > > > > know > > > > >in advance is some library is static one or just import library for some > > >dynamic one. > > > > I would be quite frankly amazed if someone couldn't write a 10-line CMake > > macro that can determine if a .LIB file is static or shared. I wonder if > > simply keying on certain ASCII keywords in the .LIB file wouldn't be good > > enough (this would need some testing though, unless someone can find a > > detailed .LIB file specification). > > > > -- > > Philip Lowman > > ___ > > CMake mailing list > > CMake@cmake.org > > http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] -DNDEBUG passed to Qt moc compiler
On Wednesday 03 September 2008 5:41:53 am Nicolas Desprès wrote:
> Hi,
>
> I'm using cmake 2.6.0 and Qt-4.4.1 commercial on windows. While trying
> to compile my Qt application in release mode using
> -DCMAKE_BUILD_TYPE=Release, I met a problem with conditional Qt slots.
> In one of my header, I have something like that:
>
> #ifndef NDEBUG
> void mySlot()
> #endif
>
> In debug mode, there is no problem. But in release mode my C++
> compiler complains that it cannot find the identifier "mySlot" when
> it compiles the source file generated by Qt's moc compiler.
>
> Adding:
> -D
> NDEBUG
>
> in the parameter file given to moc in the build tree fixed the issue.
>
> I suggest that FindQt4 module could handle such issue automatically.
>
The generated cpp files get shared by multiple configurations and build types,
so if you want the -DNDEBUG, you'll have to add it yourself.
QT_WRAP_CPP(mocfiles ${MOC_HEADERS} OPTIONS -DNDEBUG)
I don't see a way to correctly support this unless the generated cpp files go
in per-configuration directories, like object files do, and conditionally add
source files to the target based on build type. To my knowledge, even Qt's
qmake doesn't do this.
The latest CVS does a
get_directory_properties(_defines COMPILE_DEFINITIONS)
to get any other defines you might declare, but NDEBUG isn't one that applies
to all configurations.
Another options is to not use #ifndef NDEBUG, and just don't call the slot or
connect to it in a release build. I would suggest doing it this way.
Clint
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake vista tutorial?
I've been using CMake on Vista 64 for a while, even with big projects. I've not had the problems you've had from your previous posts. Clint On Wednesday 03 September 2008 10:45:14 am Craig Miller wrote: > Thanks for the reply Alex. As a new user, I wasn't aware of the wiki and > didn't think to look under the developer menu (thought it was for CMake > devs, not devs using CMake). I was following the directions under > http://www.cmake.org/HTML/Documentation.html. > > I'll take a closer look, but a quick perusal and search for "vista" didn't > seem to offer up a tutorial. Are you suggesting that the tutorial is > already there if I had only taken the time to look? > > As I mentioned in my other posts, I was willing to sort through and fully > document any Vista related issues. At this point, I'm going to hold off on > running CMake under Vista 64. While it might be possible to get it > running, I'm not willing to use an immature product (under Vista 64 anyway) > that has limited community support. I'll play around with it on a less > critical project in a few months. > > Craig > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Alexander Neundorf > Sent: Wednesday, September 03, 2008 8:57 AM > To: cmake@cmake.org > Subject: Re: [CMake] cmake vista tutorial? > > On Thursday 28 August 2008, Craig Miller wrote: > ... > > > Any links to recent tutorials would be very appreciated. > > Did you have a look at the wiki ? > It's in the "Developers" menu. > > Beside that, if you find things which are missing/wrong in the html pages > for documentation, please consider filing bug reports for the category > "Documentation", ideally already with a text which would improve the > current version attached. > > Alex > ___ > CMake mailing list > CMake@cmake.org > http://www.cmake.org/mailman/listinfo/cmake > > ___ > CMake mailing list > CMake@cmake.org > http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [vtk-developers] VTK-5-2 and Qt 4.4 build config on OSX
On Wednesday 03 September 2008 12:28:57 pm Darren Weber wrote: > In ccmake settings for VTK-5-2 with Qt 4.4 on OSX, I see a lot of > settings like this: > > QT_QTCORE_LIBRARY > optimized;/Library/Frameworks/QtCore.framework;debug;/Library/Frameworks/Qt >Core.framework QT_QTCORE_LIBRARY_DEBUG QT_QTCORE_LIBRARY_DEBUG-NOTFOUND > > The optimized and debug libraries are both specified in one variable > and missing in the other. > > The general build type is RelWithDebInfo. I don't know if the Qt > binary installation provides debug symbols (maybe I should build Qt > 4.4 from source?). > > Is this a problem to resolve? > Its not a problem at all on Mac and Unix/Linux. As long as you have something in QT_QTCORE_LIBRARY, you're fine. Some versions of Qt have separate debug and release libraries on some/all platforms. Clint ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [vtk-developers] VTK-5-2 and Qt 4.4 build config on OSX
It shouldn't make a difference to the cmake variables. The debug libraries get installed into the same frameworks. And cmake references the frameworks, not the libraries within the frameworks. To run your application with the debug libraries in the frameworks, you set the environment variable DYLD_IMAGE_SUFFIX="_debug". Clint On Wednesday 03 September 2008 1:29:41 pm Darren Weber wrote: > Thanks, Clint! > > As you say, they provide a separate debug library, ie see: > http://trolltech.com/developer/downloads/qt/mac > > qt-mac-opensource-4.4.1.dmg > qt-mac-opensource-4.4.1-debug-libs.dmg (dmg containing ONLY the debug > libraries, only usable with dmg above installed) > > I'll check this out and see if it makes any difference to the ccmake > settings. > > Best, Darren > > On Wed, Sep 3, 2008 at 11:36 AM, <[EMAIL PROTECTED]> wrote: > > On Wednesday 03 September 2008 12:28:57 pm Darren Weber wrote: > >> In ccmake settings for VTK-5-2 with Qt 4.4 on OSX, I see a lot of > >> settings like this: > >> > >> QT_QTCORE_LIBRARY > >> optimized;/Library/Frameworks/QtCore.framework;debug;/Library/Frameworks > >>/Qt Core.framework QT_QTCORE_LIBRARY_DEBUG > >> QT_QTCORE_LIBRARY_DEBUG-NOTFOUND > >> > >> The optimized and debug libraries are both specified in one variable > >> and missing in the other. > >> > >> The general build type is RelWithDebInfo. I don't know if the Qt > >> binary installation provides debug symbols (maybe I should build Qt > >> 4.4 from source?). > >> > >> Is this a problem to resolve? > > > > Its not a problem at all on Mac and Unix/Linux. As long as you have > > something in QT_QTCORE_LIBRARY, you're fine. Some versions of Qt have > > separate debug and release libraries on some/all platforms. > > > > Clint ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] shared library versioning on OS X
Perhaps this bug report fits what you are seeing. Are you seeing this limitation in the ninja generator? https://cmake.org/Bug/view.php?id=14140 Clint On Feb 20, 2016 11:49 AM, Bruce Stephens wrote: > > By the looks of it setting the SOVERSION when generating a SHARED library > creates the symbolic link, but it doesn't seem to use the -current_version or > -compatibility_version flags when linking. > > Those flags are set as variables CMAKE_C_OSX_CURRENT_VERSION_FLAG and > CMAKE_C_OSX_COMPATIBILITY_VERSION_FLAG (and similar for other languages) but > those don't seem to be used. > > Is that deliberate? > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] CPack and PackageMaker
Hi, I have updated the patch I sent before and you can find some new code here: https://github.com/clintonstimpson/CMake/commits/productbuild To help, perhaps you can review and test it. Or help in other ways you think it needs. I have done minimal testing. This includes making sure CMake's test suite passes with this generator. And running those generated pkg files manually to test them. Perhaps after a couple reviews, we can start thinking about merging into CMake. Thanks, Clint - On Dec 21, 2015, at 11:56 PM, Roman Wüger wrote: > Is there anything I can do to support? > Best regards > Am 11.12.2015 um 20:17 schrieb robert.bielik < robert.bie...@dirac.se >: >> Dear Clint, >> Thank you! Will certainly start with that as a base :) >> Regards >> /R >> -- Ursprungligt meddelande-- >> Från: >> Datum: fre, 11 dec 2015 20:12 >> Till: Robert Bielik; >> Kopia: Attila Krasznahorkay;cmake; >> Ämne: Re: [CMake] CPack and PackageMaker >> If you are interested, attached is some code I started a couple years ago but >> never finished, nor did I do much testing. >> Perhaps that'll help, or maybe you'll find a better way. >> Clint >> - On Dec 11, 2015, at 9:50 AM, Robert Bielik robert.bie...@dirac.se >> wrote: >> > Dear Attila, >> > Ok, been struggling getting an installation package to work with the >> > pkgbuild/productbild tools, so I think I got the gist of what needs to >> > be done, at least to get something going :) >> > Regards >> > /R >> > Den 2015-12-11 kl. 17:47, skrev Attila Krasznahorkay: >> >> Hi Robert, >> >> I'm afraid that the sad situation is that nobody has done this yet, or is >> >> working on it at the moment. >> >> I'm absolutely sure that if you can help with this by any amount, that >> >> will be >> >> most welcome by the CMake developers. It will certainly be most welcome >> >> by me, >> >> as I've been disappointed by the lack of this support as well. (But >> >> unfortunately can't spare the time to help out in writing this CPack >> >> generator.) >> >> Cheers, >> >> Attila >> >>> On 11 Dec 2015, at 17:44, Robert Bielik wrote: >> >>> Really ? No one ? :) >> >>> So it's ok to go ahead and start create a new one ? ;) >> >>> Rgds, >> >>> /R >> >>> Den 2015-12-09 kl. 16:56, skrev Robert Bielik: >> Mac OSX: >> Since PackageMaker has been deprecated by Apple, the new tools to use >> are >> pkgbuild [1] and productbuild [2]. >> Simple question: Is there any work being done by the CMake community on >> a new OS >> X CPack backend to support the above tools ? >> Regards >> /Robert >> [1] >> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/pkgbuild.1.html >> [2] >> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/productbuild.1.html >> >> >>> -- >> >>> Powered by www.kitware.com >>> >> >>> Please keep messages on-topic and check the CMake FAQ at: >> >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >> >>> Kitware offers various services to support the CMake community. For more >> >>> information on each offering, please visit: > CMake Support: http://cmake.org/cmake/help/support.html >>> CMake > Consulting: > http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: >> >>> http://cmake.org/cmake/help/training.html >>> >> >>> Visit other Kitware open-source projects at >> >>> http://www.kitware.com/opensource/opensource.html >>> >> >>> Follow this link to subscribe/unsubscribe: >> >>> http://public.kitware.com/mailman/listinfo/cmake > >> > -- >> > Powered by www.kitware.com > >> > Please keep messages on-topic and check the CMake FAQ at: >> > http://www.cmake.org/Wiki/CMake_FAQ > >> > Kitware offers various services to support the CMake community. For more >> > information on each offering, please visit: >>> CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: >>> http://cmake.org/cmake/help/consulting.html > CMake Training Courses: >> > http://cmake.org/cmake/help/training.html > >> > Visit other Kitware open-source projects at >> > http://www.kitware.com/opensource/opensource.html > >> > Follow this link to subscribe/unsubscribe: >> > http://public.kitware.com/mailman/listinfo/cmake >> -- >> Powered by www.kitware.com >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmak
Re: [CMake] Install with full absolute path on OS X
To set the install name to an absolute path, it would probably be something
like
set_property(TARGET EMsoft PROPERTY INSTALL_NAME_DIR
${CMAKE_INSTALL_PREFIX}/lib)
Clint
- On Apr 26, 2016, at 12:24 PM, Michael Jackson
wrote:
> I am building a library and installing onto the local system. After
> installation
> otool reports that the path is "@rpath/lib/libEMsoft.dylib"
> How can I have the installed path be the full absolute path to the library.
> For
> this use case @rpath is not going to work.
> I have tried https://cmake.org/Wiki/CMake_RPATH_handling and variations of
> that
> information but none of it seems to work.
> THanks
> --
> Mike Jackson [ mike.jack...@bluequartz.net ]
> --
> Powered by www.kitware.com
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Recommended style for multiple CPack generator folder structures
I prefer one for both installing and creating packages. install(TARGETS bar COMPONENT bar DESTINATION "./" # This must be "./" not "/" as it has to be a relative path ) Then set CMAKE_PREFIX_PATH=/Applications/Foo when you do an install. CMAKE_PREFIX_PATH will be pre-pended to relative paths given in install() commands. Clint - On May 24, 2016, at 5:40 AM, Harry Mallon ha...@codexdigital.com wrote: > In answer to my own question. One way to do it which seems quite neat is as > follows. Using multiple installs: > > install(TARGETS bar >COMPONENT bar >DESTINATION "Applications/Foo" > ) > > install(TARGETS bar >COMPONENT bar-standalone >DESTINATION "./" # This must be "./" not "/" as it has to be a relative > path > ) > > This in your CPACK_PROJECT_CONFIG_FILE: > > if (CPACK_GENERATOR STREQUAL DragNDrop) >set(CPACK_COMPONENTS_ALL bar-standalone) > endif() > > Harry > > Harry Mallon > CODEX | Software Engineer > 60 Poland Street | London | England | W1F 7NT > E ha...@codexdigital.com | T +44 203 7000 989 > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] CPack: Combine Debug and Release build
One thing I've done before is to tell cpack to bundle up 2 projects in one
cpack session.
One project is a debug build, and the other a release build.
if ( CREATE_MULTI_CONFIG_PACKAGE )
set (CPACK_INSTALL_CMAKE_PROJECTS
# self project
" ${CMAKE_CURRENT_BINARY_DIR} ; ${CMAKE_PROJECT_NAME} ;ALL;/"
# other project
" ${DIR_TO_OTHER_PROJECT} ; ${CMAKE_PROJECT_NAME} ;ALL;/"
)
endif ()
- On Aug 18, 2016, at 5:12 AM, tonka tonka wrote:
> Hey,
> I want to switch to cpack to build my zip, installer etc.. Everything works
> fine, but I am not able to get my debug build into my cpack end file. It will
> always use the release build, which is fine for end-user deployment but not
> for
> and sdk installer, because on windows I have to provide both
> build-configurations.
> Can anybody give me some advice what I can do to get such result?
> Thanks in advance
> Tonka
> --
> Powered by www.kitware.com
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] works when I build using XCode, but not with CMake makefile
It may help to include the output of "otool -L" on skedmo-solver, /usr/lib/libmysqlclient.18.dylib and /Applications/MAMP/Library/lib/libmysqlclient.18.dylib. And it may also help to see if there is a difference in the otool output in the Xcode vs makefile scenario. Also, it may help to check the output of "otool -l skedmo-solver" for both the Xcode and makefile scenario. Clint - On Sep 7, 2016, at 5:18 AM, Cotton Candy wrote: > Hi Peter, > I attach my CMakeLists.txt file as well as the FindMySQL.cmake finder that I > used, in case these help. > I still get the same error when I run the executable: > dyld: Library not loaded: libmysqlclient.18.dylib > Referenced from: /Users/schurger/tmp/test_CMake2/./skedmo-solver > Reason: image not found > Trace/BPT trap: 5 > This library (libmysqlclient.18.dylib) is in /usr/lib on my machine. > Thanks for all your help. > Aaron > On Wed, Sep 7, 2016 at 9:36 AM, Peter Steinbach < steinb...@scionics.de > > wrote: >> Hi Mr Candy (I am still getting a heck out of cottoncandycoder, sorry :D ) >> 1) the way you do it, is not really the way cmake should be used AFAIK. >> > In my CMakeLists.txt file I included: >> > set( CMAKE_CXX_FLAGS "-L/Applications/MAMP/Library/lib -lmysqlclient >> > -lpthread -lz" ) >> > set( CMAKE_EXE_LINKER_FLAGS "-lmysqlclient -lpthread -lm -lz" ) >> change this to: >> #I assume you have something like this somewhere >> add_executable(my_exe_name SOURCES my_exe_name.???) >> #here comes the "magic" >> link_directories(/Applications/MAMP/Library/lib) >> target_link_libraries(mysqlclient pthread m z) >> In theory, if all those dependencies are available at cmake-invocation, this >> should emit compiler calls that produce your binary and link mysqlclient into >> it (by default with using RPATH, see the docs on this: >> https://cmake.org/cmake/help/v3.0/prop_tgt/MACOSX_RPATH.html#prop_tgt:MACOSX_RPATH >> ). Depending on whether you wanna distribute your binary and cannot be sure >> if >> (at build time) pthreads etc are available, there are cmake find modules for >> pthreads and libz (FindThreads, FindZLIB) which you can use. libm should come >> with the libc of the system AFAIK. >> I also just checked but up to cmake 3.5, there is no MYSQL Find module. >> Which is >> kinda sad as there is a FindPostgreSQL module. :( If there would be, you >> could >> use it in a (hopefully) platform independent way and not bother with finding >> the right paths to libmysqlclient. >> 2) The compiler flags you posted do not explain, why Xcode apparently sets >> the >> rpath inside the binary and your cmake script doesn't (haven't seen the full >> CMakeLists.txt of your project yet). >> I hope the above gets you going. >> @cmake developers: it would be nice to have more obvious pointers to cmake >> example projects like an example SDK or so. If there is, please let me know. >> I >> only found this: >> http://www.vtk.org/Wiki/CMake/Examples#Finding_Packages >> but that's tied to vtk. >> Best, >> peter >> On 09/06/2016 08:12 PM, Cotton Candy wrote: >> > Peter, >> > In XCode I have this list of "settings" that includes >> > "Other Linker Flags" that I have set to "-lmysqlclient -lpthread -lm -lz" >> > and >> > "Other C++ Flags" that I have set to "-L/Applications/MAMP/Library/lib >> > -lmysqlclient -lpthread -lz" >> > Maybe these explain why things work when I build with XCode, but not with >> > CMake. >> > but when I run the make it always says it is ignoring these (e.g. "warning: >> > argument unused during compilation: '-L/Applications/MAMP/Library/lib'"). >> > Thanks again for you help. >> > Aaron >> > On Tue, Sep 6, 2016 at 2:20 PM, Peter Steinbach < steinb...@scionics.de > >> > wrote: >> >> Aaron, >> >> it's about the way that you compile your binary and link libmysqlclient >> >> into it. I guess (@all: please correct me if I am wrong) as I don't know >> >> how you use cmake to build your libraries/binaries, that you don't set the >> >> rpath of libmysqlclient inside your binary. Doing so will ensure that the >> >> absolute path of libmysqlclient is stored into your binary, so that the >> >> runtime environment can pick it up and use (keeping fingers crossed that >> >> the path is still valid). The alternative to doing so, is linking against >> >> the static version of libmysqlclient (which comes at a cost on another >> >> front as well). >> >> Best, >> >> P > -- > Powered by www.kitware.com > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > Follow this link to su
Re: [CMake] works when I build using XCode, but not with CMake makefile
- On Sep 7, 2016, at 12:52 PM, Cotton Candy wrote: > Here is the output from otool -L on skedmo-solver that you requested: > skedmo-solver: > libmysqlclient.18.dylib (compatibility version 18.0.0, current version 18.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version > 1197.1.1) > /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5) > /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0) > on /usr/lib/libmysqlclient.18.dylib I get an error > aaron-schurgers-computer-3:lib schurger$ otool -L libmysqlclient.18.dylib > error: > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/otool: > can't open file: libmysqlclient.18.dylib (No such file or directory) > even though the file libmysqlclient.18.dylib is clearly there when I do ls Try doing "ls -l" Perhaps its a softlink to a file which doesn't exist. Clint -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Browse buttons in CMake-Gui give URL cannot be listed Malformed URL error (Manjaro KDE Plasma 5.7 Qt 5.7)
Hi, Thanks for reporting this. I was also able to reproduce it. The problem comes from cmake-gui calling QApplication::removeLibraryPath() in CMakeSetup.cxx. I think the solution is to remove that bit of code, but it may require some additional cpack related code to handle plugins correctly. It appears we are doing that cpack code for Windows and Mac already, but not for Linux (see CMake/Source/QtDialog/CMakeLists.txt line 48 to 85). Clint - On Sep 20, 2016, at 4:18 PM, cmake wrote: > Hi. > When I click "Browse source" or "Browse build" location buttons in the GUI I > get > an error dialog saying that "URL cannot be listed file://" followed by another > dialog "Malformed URL". > 1. I built and reinstalled CMake from source but the problem persists. > 2. I searched the web but could not find anyone reporting this issue for > CMake. >3. When I launch CMake-gui from terminal, when I click the Browse buttons > it >prints "kf5.kio.core: Refilling KProtocolInfoFactory cache in the hope to > find >"file"" in the terminal. I tried looking up for this message but again I > could > not find anything about CMake. > Please let me know if you need some logs. > Machine: x64, Manjaro KDE Plasma 5.7, Qt 5.7 Nvidia GTX 960m, i7-6700 HQ > Regards, > Amit > -- > Powered by www.kitware.com > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Browse buttons in CMake-Gui give URL cannot be listed Malformed URL error (Manjaro KDE Plasma 5.7 Qt 5.7)
- On Sep 20, 2016, at 4:18 PM, cmake wrote: > Hi. > When I click "Browse source" or "Browse build" location buttons in the GUI I > get > an error dialog saying that "URL cannot be listed file://" followed by another > dialog "Malformed URL". > 1. I built and reinstalled CMake from source but the problem persists. > 2. I searched the web but could not find anyone reporting this issue for > CMake. >3. When I launch CMake-gui from terminal, when I click the Browse buttons > it >prints "kf5.kio.core: Refilling KProtocolInfoFactory cache in the hope to > find >"file"" in the terminal. I tried looking up for this message but again I > could > not find anything about CMake. > Please let me know if you need some logs. > Machine: x64, Manjaro KDE Plasma 5.7, Qt 5.7 Nvidia GTX 960m, i7-6700 HQ > Regards, > Amit Hi Amit, This should fix your problem. Can you verify? https://cmake.org/gitweb?p=cmake.git;a=commit;h=48624b3c Thanks, Clint -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] CMake 3.7.0-r2 Open Project sometimes picks wrong version of Visual Studio
- On Nov 8, 2016, at 8:13 AM, Taylor Braun-Jones tay...@braun-jones.org
wrote:
> On Fri, Nov 4, 2016 at 2:55 PM, Brad King wrote:
>>
>> On 11/03/2016 06:04 PM, John Drescher wrote:
>> > I opened a project in cmake-gui using the open project button from a
>> > vc 2010 build of a project. The open project opened the project in
>> > Visual Studio 2010. Later I opened the same project but a different
>> > build tree for Visual Studio 2013 CMake-gui had all of the correct
>> > information for the Visual Studio 2013 build but open project tried to
>> > open the Visual Studio 2013 solution in Visual Studio 2010 instead of
>> > the expected Visual Studio 2013.
I'm unable to reproduce this problem. I have multiple Visual Studio
installations of different versions.
I'm not sure whether it could be specific to a project, or specific to
installations of visual studio.
>
> I'm guessing you established MSVS2010 as the default application for
> opening .sln files the first time you used the open project button.
> What happens if you double click on that MSVS2013 .sln file?
>
>> The feature is new in 3.7 and was contributed here:
>>
>> cmake-gui: Add button to open the generated project
>> https://gitlab.kitware.com/cmake/cmake/commit/1ca2d5d1
>>
>> I'm not particularly familiar with how it works, but from a quick
>> glance at the code it may be using file associations.
>
> Yes, it's just using Windows file file associations, but it shouldn't.
> Since it's possible (and fairly common) to have more than one version
> of Visual Studio installed on a system the Open Project button should
> be smarter and use ${CMAKE_VS_DEVENV_COMMAND} to open the .sln file.
> It should be something like this:
>
> MSVS2015: %VS140COMNTOOLS%..\IDE\devenv.com
> MSVS2013: %VS120COMNTOOLS%..\IDE\devenv.com
> MSVS2012: %VS110COMNTOOLS%..\IDE\devenv.com
> MSVS2010: %VS100COMNTOOLS%..\IDE\devenv.com
>
> If the correct devenv.exe path does not exist or can't be determined
> for some reason, then I guess it makes sense to fall back to using
> `QDesktopServices::openUrl` to try to open the .sln file with the
> Windows file associations.
It is already using QDesktopServices::openUrl(QUrl::fromLocalFile(...))
AFAIK, that is the correct way to do it. The .sln file should already know
what version of Visual Studio it wants to be opened in.
Clint
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Force MSVC runtime for debug builds
- On Nov 7, 2016, at 1:37 AM, Stephan Menzel wrote: > Hello everyone, > I'm looking for a way to force Debug configurations in generated MSVC > solutions > to use the Release runtime instead of the default "Debug". e.g. /MD rather > than > /MDd. > My use case is an ever recurring problem of creating libraries that are linked > in plug-in fashion against Release only applications. I want for my Debug > configuration to have debug info and no optimization but still use the release > runtime so I can link them. > I tried replacing /MDd with /MD in CMAKE_CXX_FLAGS_DEBUG. This yielded objects > built with /MD alright but failed to link into an executable with stuff like > that: > error LNK2038: mismatch detected for 'RuntimeLibrary': value > 'MD_DynamicRelease' > doesn't match value 'MDd_DynamicDebug' in Test.obj > From what I gather all the obj are actually compiled for Release runtime > without > optimization and Debug info just like I need it. But then the main obj is > built > and linked in Debug mode, causing the executable to not be created. > Is there a way to solve this? Like a generic CMake executable flag or > something > that I can use to force the other runtime? > Please note that using RelWithDebInfo and turning off optimization is not > exactly what I need as I still want that mode much the way it is. If you are going to use /MD instead of /MDd, then you probably also need to remove the _DEBUG preprocessor flag. IIRC, I've seen cases where defining _DEBUG includes symbols only defined by the debug runtimes. Clint -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Full absolute path as RPATH in build tree
Do you want the library identification to be a full path? set_target_properties(foo PROPERTIES MACOSX_RPATH OFF) Clint - On Dec 5, 2016, at 7:38 PM, Michael Jackson mike.jack...@bluequartz.net wrote: > what combinations of RPATH variables do I need to set to get a full, > absolute path to a build library in my build tree? THis is on macOS > 10.10.5 and cmake 3.5 and above. I have tried all sorts of combinations > and I either get just the library name or @rpath/library.dylib neither > of which is going to work for my needs. > > Thanks > > -- > Michael A. Jackson > BlueQuartz Software, LLC > [e]: mike.jack...@bluequartz.net > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Full absolute path as RPATH in build tree
If you want the INSTALL_NAME_DIR to have effect in the build tree, you also need
set_target_properties(EMsoftLib PROPERTIES BUILD_WITH_INSTALL_RPATH ON)
Clint
- On Dec 5, 2016, at 8:22 PM, Michael Jackson mike.jack...@bluequartz.net
wrote:
> I have this:
>
> if(APPLE AND BUILD_SHARED_LIBS)
> set_target_properties(EMsoftLib PROPERTIES MACOSX_RPATH FALSE)
> set_target_properties(EMsoftLib PROPERTIES INSTALL_NAME_DIR
> "${CMAKE_LIBRARY_OUTPUT_DIRECTORY}")
> endif()
>
> --
> Michael A. Jackson 400 S. Pioneer Blvd
> Owner, President Springboro, Ohio 45066
> BlueQuartz Software, LLC EMail: mike.jack...@bluequartz.net
> Voice: 937-790-1601Web: http://www.bluequartz.net
> Fax: 937-746-0783
>
>
> clin...@elemtech.com wrote:
>> Do you want the library identification to be a full path?
>> set_target_properties(foo PROPERTIES MACOSX_RPATH OFF)
>>
>> Clint
>>
>> - On Dec 5, 2016, at 7:38 PM, Michael Jackson mike.jack...@bluequartz.net
>> wrote:
>>
>>> what combinations of RPATH variables do I need to set to get a full,
>>> absolute path to a build library in my build tree? THis is on macOS
>>> 10.10.5 and cmake 3.5 and above. I have tried all sorts of combinations
>>> and I either get just the library name or @rpath/library.dylib neither
>>> of which is going to work for my needs.
>>>
>>> Thanks
>>>
>>> --
>>> Michael A. Jackson
>>> BlueQuartz Software, LLC
>>> [e]: mike.jack...@bluequartz.net
>>> --
>>>
>>> Powered by www.kitware.com
>>>
>>> Please keep messages on-topic and check the CMake FAQ at:
>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Kitware offers various services to support the CMake community. For more
>>> information on each offering, please visit:
>>>
>>> CMake Support: http://cmake.org/cmake/help/support.html
>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
> >> http://public.kitware.com/mailman/listinfo/cmake
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] How to use a generated linker map with a shared library?
On Jan 14, 2017 7:16 PM, Paul Smith wrote:On Sun, 2017-01-15 at 12:08 +1100, Craig Scott wrote: > While not directly answering your question, it seems you may be trying > to deal with symbol visibility. Are you aware of CMake's symbol > visibility features? A good place to start would be the > GenerateExportHeader module, the documentation for which does a > reasonable job of showing how to use the visibility features CMake > provides. Yes, thanks for that info. My situation is that I need to force ALL symbols to be private, even those from external static shared libraries that I'm linking in (whose symbols have global visibility by default). Have you tried the "--exclude-libs ALL" linker option? Using that should hide symbols from static libraries.Clint-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] OSX RPATH linker flags not added on first build
- On Feb 3, 2017, at 11:25 AM, Doug Digglington
wrote:
> Hello,
> I am using ExternalProject to download and build a third-party library (SDL)
> in
> my project. I am running into an issue on OSX where the RPATH linker flags
> will
> not be added when my project is built and linked for the first time. As a
> result the built executable will not have any RPATH paths in it. However, when
> I rerun CMake or touch the main CMakeLists.txt file and rebuild then the
> linker
> flags will be added appropriately.
> I have tried explicitly setting the RPATH variables according to the "CMake
> RPATH handling" page both for the default and "always full" scenarios but that
> did not seem to change this behavior. Here is my current CMakeLists.txt file:
> cmake_minimum_required(VERSION 3.5)
> project(shared_object)
> set(CMAKE_MACOSX_RPATH TRUE)
> set(LIB_INSTALL_DIR ${CMAKE_INSTALL_PREFIX}/sdl/install)
> set(LIB_DIR ${LIB_INSTALL_DIR}/lib)
> set(LIB_PATH
> ${LIB_DIR}/${CMAKE_SHARED_LIBRARY_PREFIX}SDL2${CMAKE_SHARED_LIBRARY_SUFFIX})
> include(ExternalProject)
> ExternalProject_Add(
> libsdl
> PREFIX ${CMAKE_BINARY_DIR}/sdl
> URL [ https://www.libsdl.org/release/SDL2-2.0.5.tar.gz |
> https://www.libsdl.org/release/SDL2-2.0.5.tar.gz ]
> URL_MD5 d4055424d556b4a908aa76fad63abd3c
> CMAKE_ARGS
> -DCMAKE_INSTALL_PREFIX=${LIB_INSTALL_DIR}
> -DCMAKE_MACOSX_RPATH=${CMAKE_MACOSX_RPATH}
> -DSDL_STATIC=FALSE
> INSTALL_DIR ${LIB_INSTALL_DIR}
> )
> add_library(sdl SHARED IMPORTED GLOBAL)
> set_target_properties(sdl PROPERTIES
> IMPORTED_LOCATION ${LIB_PATH}
> )
You could try adding another property here.
set_target_properties(sdl PROPERTIES IMPORTED_SONAME "@rpath/
${CMAKE_SHARED_LIBRARY_PREFIX}SDL2${CMAKE_SHARED_LIBRARY_SUFFIX}")
With that hint, CMake would not need to wait until the library exists before
being able to find out if it uses @rpath.
And I see you also set CMAKE_MACOSX_RPATH=TRUE. That will only have an effect
on any add_library() calls within the current scope (excluding imported
libraries).
Clint
> add_dependencies(sdl libsdl)
> add_executable(shared_object main.cpp)
> target_link_libraries(shared_object sdl)
> When I run CMake for the first time here are the contents of the
> CMakeFiles/shared_object.dir/link.txt file:
> /Applications/Xcode_6.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
> -Wl,-search_paths_first -Wl,-headerpad_max_install_names
> CMakeFiles/shared_object.dir/main.cpp.o -o shared_object
> sdl/install/lib/libSDL2.dylib
> Notice that there are no -Wl,-rpath linker flags. When I run `make` to build
> the
> project there is no RPATH information in the built executable. I checked this
> with `otool -l shared_object | grep -A2 RPATH`.
> Now if I rerun CMake after everything has been built or if I touch the
> CMakeLists.txt file before running `make` again then the contents of the
> CMakeFiles/shared_object.dir/link.txt changes and the RPATH information is
> linked into the built application. Here is the contents of
> CMakeFiles/shared_object.dir/link.txt after I rerun CMake:
> /Applications/Xcode_6.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
> -Wl,-search_paths_first -Wl,-headerpad_max_install_names
> CMakeFiles/shared_object.dir/main.cpp.o -o shared_object
> -Wl,-rpath,/var/tmp/so/sdl/install/lib sdl/install/lib/libSDL2.dylib
> After rebuliding the application it will contain the expected RPATH
> information:
> otool -l shared_object | grep -A2 RPATH
> cmd LC_RPATH
> cmdsize 40
> path /var/tmp/so/sdl/install/lib (offset 12)
> Is there something that I am configuring incorrectly about the external
> project
> or imported library that causes it to not be known or added to the linker
> flags
> the first time CMake is run?
> --
> Powered by www.kitware.com
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscrib
Re: [CMake] Install rpath handling for iOS frameworks [solved-ish]
It looks like you want the default behavior, but from what you show,
I don't know what is disabling it. The default behavior does not require
you to set the XCODE_ATTRIBUTE_LD_DYLIB_INSTALL_NAME, nor does it require you
to call install_name_tool yourself at install time to get @rpath.
Not getting @rpath could be from the old behavior of CMP0042,
setting MACOSX_RPATH = 0, or setting INSTALL_NAME_DIR = "".
I think those are the only 3 factors, but in older versions of CMake, before
CMP0068,
there were more variables which could affect it.
If you are doing cross compiling with a toolchain file, maybe its something
else,
such as the setting of CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG.
Clint
- On Oct 20, 2017, at 2:40 AM, Robert Bielik robert.bie...@dirac.com wrote:
> Ok, this is most certainly not the way to do it, but I added two install
> steps:
>
> install(CODE "SET(FRAMEWORK_SO \"dummy.framework/dummy\")")
> install(SCRIPT add_rpath.cmake COMPONENT frameworks)
>
> add_rpath.cmake:
>
> # Adds @rpath to the SO in the framework because CMake install removes it
> (!!!)
> EXECUTE_PROCESS(
>COMMAND install_name_tool -id "@rpath/${FRAMEWORK_SO}" ${FRAMEWORK_SO}
>WORKING_DIRECTORY ${CMAKE_INSTALL_PREFIX}
> )
> #
>
> And this works with install target and packaging. But it is ugly.
> /R
>
>> -Original Message-
>> From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Robert
>> Bielik
>> Sent: den 20 oktober 2017 08:32
>> To: Cmake@cmake.org
>> Subject: Re: [CMake] Install rpath handling for iOS frameworks
>>
>> Running 3.9.4 I see that behavior related to RPATH on macOS has changed:
>>
>> https://cmake.org/cmake/help/v3.9/policy/CMP0068.html
>>
>> I've tried setting the policy to OLD, but I'm just not able to get
>> @rpath/... to
>> propagate to the install ☹
>>
>> Ideas, please ?
>> /R
>>
>> > -Original Message-
>> > From: Robert Bielik
>> > Sent: den 19 oktober 2017 16:14
>> > To: Robert Bielik ; Cmake@cmake.org
>> > Subject: RE: Install rpath handling for iOS frameworks
>> >
>> > Oh, and I just added:
>> >
>> > SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
>> >
>> > But it doesn't change anything.
>> >
>> > /R
>> >
>> > > -Original Message-
>> > > From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Robert
>> > > Bielik
>> > > Sent: den 19 oktober 2017 16:09
>> > > To: Cmake@cmake.org
>> > > Subject: [CMake] Install rpath handling for iOS frameworks
>> > >
>> > > I'm trying to package an iOS framework, and with the target setting:
>> > >
>> > > XCODE_ATTRIBUTE_LD_DYLIB_INSTALL_NAME
>> > > "@rpath/$(EXECUTABLE_PATH)"
>> > >
>> > > I get the framework built nicely. otool -L dummy.framework/dummy
>> > shows
>> > >
>> > >@rpath/dummy.framework/dummy
>> > >
>> > > Just as it should. Now I have a install directive:
>> > >
>> > > install(TARGETS dummy
>> > > FRAMEWORK DESTINATION "./" COMPONENTS frameworks)
>> > >
>> > > Then I do cpack -G ZIP, and it all packages together without a hitch.
>> > > But when I do otool -L of the dummy.framework/dummy from where
>> the
>> > > package is built I get:
>> > >
>> > >dummy.framework/dummy
>> > >
>> > > i.e. @rpath has been removed during the install process ?
>> > >
>> > > What am I doing wrong ?
>> > >
>> > > TIA
>> > > /Robert
>> > >
>> > > --
>> > >
>> > > Powered by www.kitware.com
>> > >
>> > > Please keep messages on-topic and check the CMake FAQ at:
>> > > http://www.cmake.org/Wiki/CMake_FAQ
>> > >
>> > > Kitware offers various services to support the CMake community. For
>> > > more information on each offering, please visit:
>> > >
>> > > CMake Support: http://cmake.org/cmake/help/support.html
>> > > CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> > > CMake Training Courses: http://cmake.org/cmake/help/training.html
>> > >
>> > > Visit other Kitware open-source projects at
>> > > http://www.kitware.com/opensource/opensource.html
>> > >
>> > > Follow this link to subscribe/unsubscribe:
>> > > http://public.kitware.com/mailman/listinfo/cmake
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please
Re: [CMake] FindQt4 for Qt 4.2.0 does not recognise debug-libs
> Filipe Sousa schrieb: > > Jens wrote: > >> Hi, > >> > >> FindQt4.cmake does not handle the new filenames of Qt-4.2.0-debug-libs. > >> > >> I compiled Qt 4.2.0 from source and see that the debug-libs changed > >> their names to "libQt*.so.4.2.0.debug" on linux. > > > > These are not debug libraries. Qt 4.2.0 by default splits the debug info > > from libraries with objcopy: > > > > objcopy --only-keep-debug "$targ" "$targ.debug" && objcopy > > --strip-debug "$targ" && objcopy --add-gnu-debuglink="$targ.debug" > > "$targ" > > > > AFAIK qt 4.2.0 does not generate debug and release libs at the same sime > > That?s interesting and sound like a real good idea. But that still means > there is a fix for FoundQt4.cmake needed. > > If I understand the mails at > http://lists.trolltech.com/qt4-preview-feedback/2006-09/thread00083-0.html > correctly, the QT_*_LIBRARY?s and QT_*_LIBRARY_DEBUG?s from > FindQt4.cmake must be the same if QTVERSION in FindQt.cmake matches "4.2.*" > > Is that correct? > > Greetings > Jens If I understand you correctly, I don't think we need to fix FindQt4.cmake. I don't think QT_*_LIBRARY_DEBUG should have the same value as QT_*_LIBRARY (for Qt 4.2). In Qt 4.2 and on Windows, the QT_*_LIBRARY_DEBUG variables still be used to link the proper Qt libraries for a debug build. I've only seen the _DEBUG suffix is for those that have separate debug libraries. For example, on Windows, you can have python24 and python24_d. If python24_d doesn't exist, PYTHON_DEBUG_LIBRARY isn't set to the value of PYTHON_LIBRARY, even on Unix platforms. Clint ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindQt4 and QTUITOOLS
> Hello all,
> I don't know if it's my system or not, but my QT_INCLUDES, don't
> include the path to QtUITools when i use the FindQt4.cmake
> Is it a way to do that properly ?
>
> thanks
> Xavier
>
FIND_PACKAGE(Qt4)
SET(QT_USE_QTUITOOLS TRUE)
INCLUDE(${QT_USE_FILE})
And if CMake didn't find the UiTools include path properly, you can manually
help it, or apply the patch found in this bug report.
http://www.cmake.org/Bug/bug.php?op=show&bugid=3766&pos=29
Clint
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] install name for fortran dylibs on mac
- Original Message - > Hi, > After much head scratching and googling, I found a way to get the dynamic > library built in a project of mine to have the correct install name, so long > as `DESTDIR=/some/path` is NOT specified upon install. Basically I want to > export the library from both the build tree and the install tree so that > client projects can choose whether or not they want to install the project > (which provides static and dynamic libraries) or just link against it from > the build tree. (If they choose to link against the dylib in the build tree > the this could cause them issues down the road, for example if they `make > clean`, but the implications of linking against a dylib in the build tree > seem fairly obvious.) Right now I am doing this by using the > CMAKE_INSTALL_NAME_DIR variable. I just have the full path to the install > directory in that variable. This way when I build it CMake is smart enough > to use the build tree as the install name, then change it during the > install. However, it would be nice to be able to support DESTDIR. > Is there a way to do this? Or a better way than I am currently doing it? > Should I be building a framework or bundle on mac… the using > `fixup_bundle()` or the like… This seems like overkill for this library, but > maybe it’s the only portable easy way to do this. Or maybe I could call > install_name_tool after the install to ensure that the dylib knows the full > absolute path to itself? I would suggest the following as a better way: Use at least CMake 2.8.12 and in your library project add this: set(CMAKE_MACOSX_RPATH 1) The install name will have @rpath, and the dylib is relieved of the burden of knowing the absolute path to itself, in both the build tree and install tree. The burden is shifted to the client knowing the location of the library it is linking against, which it already knows anyway, but there is another linker flag (-rpath) specifying that path. Clients should also use CMake 2.8.12 or newer. For more details: http://www.kitware.com/blog/home/post/510 Clint -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] install name for fortran dylibs on mac
When using @rpath, the proper way to the executable to find it at runtime is for the executable to have an rpath with a directory that contains the dylib. When compiling the executable, the linker flag "-rpath /path/to/dylib" should be given. This should be automatic with CMake when building the executable, and if it isn't doing that for you, please give us an example. To verify, the executable has the rpath, you can run "otool -l | grep LC_RPATH -A2" Clint - Original Message - > So I noticed the CMAKE_MACOSX_RPATH variable, and tried setting it, which > does result in the install name of the dylib being set to > @rpath/dylibname.so BUT when I link it in an executable tool -L just shows > the dylib as @rpath/dylibname.so and the linker fails to find it at run > time. What is the proper way to get CMake to build the executable linking > against the dylib and be able to run it in the build tree and install tree? > Izaak Beekman > === > (301)244-9367 > UMD-CP Visiting Graduate Student > Aerospace Engineering > ibeek...@umiacs.umd.edu > ibeek...@umd.edu > On Sat, May 3, 2014 at 10:54 AM, Dan Kegel < d...@kegel.com > wrote: > > On Sat, May 3, 2014 at 7:17 AM, < clin...@elemtech.com > wrote: > > > > Use at least CMake 2.8.12 and in your library project add this: > > > > set(CMAKE_MACOSX_RPATH 1) > > > > ... > > > > For more details: > > > > http://www.kitware.com/blog/home/post/510 > > > What he said. See also past discussion at > > > http://web.archiveorange.com/archive/v/5y7PkspCBZwiWhvodZSP > > > I put together some tiny demos showing various ways to do it, with > > > walkthroughs, at > > > http://kegel.com/macosx/rpath/ > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] install name for fortran dylibs on mac
I've attached a sample project which includes 2 external projects, where the executable links with the library from its build tree. After it is built, you can run it from the build tree ./app-prefix/src/app-build/app Clint - Original Message - > When using @rpath, the proper way to the executable to find it at runtime is > for the executable to have an rpath with a directory that contains the > dylib. > When compiling the executable, the linker flag "-rpath /path/to/dylib" should > be given. This should be automatic with CMake when building the executable, > and if it isn't doing that for you, please give us an example. > To verify, the executable has the rpath, you can run "otool -l | > grep LC_RPATH -A2" > Clint > - Original Message - > > So I noticed the CMAKE_MACOSX_RPATH variable, and tried setting it, which > > does result in the install name of the dylib being set to > > @rpath/dylibname.so BUT when I link it in an executable tool -L just shows > > the dylib as @rpath/dylibname.so and the linker fails to find it at run > > time. What is the proper way to get CMake to build the executable linking > > against the dylib and be able to run it in the build tree and install tree? > > > Izaak Beekman > > > === > > > (301)244-9367 > > > UMD-CP Visiting Graduate Student > > > Aerospace Engineering > > > ibeek...@umiacs.umd.edu > > > ibeek...@umd.edu > > > On Sat, May 3, 2014 at 10:54 AM, Dan Kegel < d...@kegel.com > wrote: > > > > On Sat, May 3, 2014 at 7:17 AM, < clin...@elemtech.com > wrote: > > > > > > > Use at least CMake 2.8.12 and in your library project add this: > > > > > > > set(CMAKE_MACOSX_RPATH 1) > > > > > > > ... > > > > > > > For more details: > > > > > > > http://www.kitware.com/blog/home/post/510 > > > > > > What he said. See also past discussion at > > > > > > http://web.archiveorange.com/archive/v/5y7PkspCBZwiWhvodZSP > > > > > > I put together some tiny demos showing various ways to do it, with > > > > > > walkthroughs, at > > > > > > http://kegel.com/macosx/rpath/ > > > > -- > Powered by www.kitware.com > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake test-rpath.tar.gz Description: application/compressed-tar -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Mac @loader_path for @rpath questions
- Original Message -
> I have a bunch of libraries and frameworks that properly use @rpath.
> Now I am trying to build an application that uses those library and
> frameworks via CMake.
>
> From this blog:
> http://www.kitware.com/blog/home/post/510
> I see I am supposed to do:
> set(CMAKE_MACOSX_RPATH 1)
The above should be set before declaring an @rpath target, which is one that
has an install name with @rpath.
> set_target_properties(bar PROPERTIES INSTALL_RPATH "@loader_path/../lib")
The above should be set for any targets that use an @rpath target. So those 2
lines don't necessarily go together.
>
> So now, I am trying to improve my user experience with this. So a
> couple of questions:
>
> 1) I noticed it only applies the @loader_path stuff when I "install"
> with CMake. I would like this applied during build because "install"
> is very unnatural on Mac where drag-and-drop is king. I was expecting
> set(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE) to help, but it doesn't seem
> to have an affect.
Setting CMAKE_BUILD_WITH_INSTALL_RPATH should have an effect, if set before any
targets that link with the @rpath libraries.
Can you provide an example of what you are doing, so we can find out why its
not working for you?
I understand drag-and-drop, but it doesn't work for my situations. I have
several 3rd party libraries that are not in system locations, and are not part
of the build tree, so setting CMAKE_BUILD_WITH_INSTALL_RPATH breaks my builds.
Install time is where I get a complete .app bundle.
>
>
> 2) I have both .dylibs and .frameworks. It is customary to bundle
> frameworks in .app/Contents/Frameworks/ and somewhat customary to
> bundle .dylibs in ./app/Contents/lib
> This means I need to specify multiple "Runtime Search Path"
> (LD_RUNPATH_SEARCH_PATHS) which Apple/Xcode fully allows, i.e. I need
> both:
> set_target_properties(bar PROPERTIES INSTALL_RPATH
> "@loader_path/../Frameworks")
> set_target_properties(bar PROPERTIES INSTALL_RPATH "@loader_path/../lib")
> How do I declare this for CMake?
>
With a list.
set_target_properties(bar PROPERTIES INSTALL_RPATH
"@loader_path/../Frameworks;@loader_path/../lib")
>
> 3) What is the common way people copy their frameworks into their .app
> bundle now-a-days?
I do it at install time by setting the install destination to be inside the
.app bundle.
> I was hoping I could get away with:
>
> SET_SOURCE_FILES_PROPERTIES(
> ${MY_LIBRARIES}
> PROPERTIES
> MACOSX_PACKAGE_LOCATION Frameworks
> )
> But CMake just creates an empty directory like:
> .app/Contents/Frameworks/ALmixer.framework
> with none of the stuff inside the framework. (It doesn't recursively
> copy the directory.)
I've never used MACOSX_PACKAGE_LOCATION, so I'm not sure how it works.
Clint
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMAKE_CFG_INTDIR
- Original Message -
> On 15/09/14 12:01, Daniele E. Domenichelli wrote:
> > Is there an alternative variable for CMAKE_CFG_INTDIR that can be used
> > in configure time, instead of build time?
> >
> > If there is not, is it safe to assume that the name of the directory is
> > equal to the name of the current configuration?
>
>
> Bump?
>
> What I would like to do is to be able to change
> CMAKE_RUNTIME_OUTPUT_DIRECTORY (and similar variables) with something
> that contains the current configuration directory, i.e.
>
> set(CMAKE_RUNTIME_OUTPUT_DIRECTORY .../${CMAKE_CFG_INTDIR}/...)
>
> but unfortunately CMAKE_CFG_INTDIR causes an error when targets are
> installed.
As expected, that will not work. CMAKE_CFG_INTDIR can give the build tool a
variable, which is expanded by the build tool, and you've effectively added
another configuration directory level.
You could end up with a directory such as
/path/to/Debug/Debug/
>
> I was able to have something that works as I expect by doing this:
>
> foreach(config ${CMAKE_CONFIGURATION_TYPES})
> string(TOUPPER ${config} CONFIG)
> set(CMAKE_RUNTIME_OUTPUT_DIRECTORY_${CONFIG} .../${config}/...)
> endforeach()
>
> But I was wondering if it is safe to assume that the current directory
> is always "${config}" or if it might be different.
>
That should work just fine. CMAKE_CONFIGURATION_TYPES gives you a list of all
possible configuration that can be chosen at build time.
Clint
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Installation corrupts library on OS X
- Original Message - > Hi, > I'm using CMake 3.0.2 on OS X 10.9.4. When I do a "make install", it's > somehow corrupting some of my libraries at install time. > Here is what otool reports for the library in my build directory - that is, > the state of the library prior to installation: > $ otool -L libOpenMMAmoebaCUDA.dylib > libOpenMMAmoebaCUDA.dylib: > /Users/peastman/workspace/openmm/bin-release/libOpenMMAmoebaCUDA.dylib > (compatibility version 0.0.0, current version 0.0.0) > @rpath/CUDA.framework/Versions/A/CUDA (compatibility version 1.1.0, current > version 6.0.37) > /Users/peastman/workspace/openmm/bin-release/libOpenMM.dylib (compatibility > version 0.0.0, current version 0.0.0) > @rpath/libcudart.6.0.dylib (compatibility version 0.0.0, current version > 6.0.37) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version > 1197.1.1) > /Users/peastman/workspace/openmm/bin-release/libOpenMMCUDA.dylib > (compatibility version 0.0.0, current version 0.0.0) > /Users/peastman/workspace/openmm/bin-release/libOpenMMAmoeba.dylib > (compatibility version 0.0.0, current version 0.0.0) > /usr/local/cuda/lib/libcuda.dylib (compatibility version 1.1.0, current > version 6.0.37) > @rpath/libcufft.6.0.dylib (compatibility version 0.0.0, current version > 6.0.37) > /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version > 120.0.0) > No problems. Everything looks ok. Now here is what it reports for the same > library in the install directory - the is, the state of the library after > installation: > $ otool -L /usr/local/openmm/lib/plugins/libOpenMMAmoebaCUDA.dylib > /usr/local/openmm/lib/plugins/libOpenMMAmoebaCUDA.dylib: > @rpath/libOpenMMAmoebaCUDA.dylib (compatibility version 0.0.0, current > version 0.0.0) > @rpath/CUDA.framework/Versions/A/CUDA (compatibility version 1.1.0, current > version 6.0.37) > @rpath/libOpenMM.dylib (compatibility version 0.0.0, current version 0.0.0) > @rpath/libcudart.6.0.dylib (compatibility version 0.0.0, current version > 6.0.37) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version > 1197.1.1) > @rpath/libOpenMMCUDA.dylib (compatibility version 0.0.0, current version > 0.0.0) > @rpath/libOpenMMAmoeba.dylib (compatibility version 0.0.0, current version > 0.0.0) > /usr/local/cuda/lib/libcuda.dylib (compatibility version 1.1.0, current > version 6.0.37) > @rpath/libcufft.6.0.dylib (compatibility version 0.0.0, current version > 6.0.37) > /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version > 120.0.0) > load command 22 size zero (can't advance to other load commands) > As expected, the absolute paths have been replaced by relative paths. But it > also now reports an error message at the end about "load command 22 size > zero". This error does not prevent the library from actually being loaded. > It seems to work fine as far as that is concerned. However, if I try to use > install_name_tool to make any further changes to the paths in the library it > fails with an error message: > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: > for architecture i386 object: > /usr/local/openmm/lib/plugins/libOpenMMAmoebaCUDA.dylib malformed object > (load command 22 cmdsize is zero) > Any idea what's going on? Yeah, I think you have duplicate LC_RPATH load commands. In that case, your binaries can be corrupted by install_name_tool during "make install." To check if that is your case, you can run this on the binary before installation to see if you have duplicates. otool -l app | grep -A2 LC_RPATH If the duplicates come from your own linker flags such as, -Wl,-rpath,/some/path, you may need to remove those. Otherwise, it would help if you can provide a minimal test case to reproduce the problem. It would also help if someone could report this corruption by install_name_tool bug to Apple. You are the second to come to this mailing list about this bug. Clint -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] CPack: .desktop files with tar.gz maker?
- Original Message - > On 11/7/14, Clinton Stimpson wrote: > > On Friday, November 07, 2014 03:50:32 PM Eric Wing wrote: > >> I have a build and packaging system where I can distribute (mostly) > >> standalone apps for Linux desktop. I am using the default CPack > >> installer which creates .tar.gz, .Z, and .sh files. > >> > >> I like this opposed to the .deb/.rpm package systems because users > >> don't need root access to install/use my stuff (and can place > >> anywhere), and I only need a single package for all Linux desktops. > >> > >> But it's pretty plain-Jane and it would be nice to provide an icon or > >> something. So I was wondering if anybody had > >> suggestions/advice/strategies on supporting .desktop files. As far as > >> I can tell, I need paths to the icon and the executable, which is > >> completely variable based on where the user puts it. And I'm not sure > >> where this file is supposed to be written to. (Remember that I don't > >> use root access.) > >> > >> Thanks, > >> Eric > > > > Perhaps you can do this: > > > > Include the .desktop file in your installation. > > > > To add, your installer can call > > xdg-desktop-menu install /share/applications/MyApp.desktop > > > > To remove, your installer can call > > xdg-desktop-menu uninstall /share/applications/MyApp.desktop > > > > If xdg-desktop-menu is called as root, it'll copy the .desktop file to the > > system location. If it is called as a non-root user, it'll copy the file > > to > > > > the user specific desktop area. xdg-desktop-menu also takes care of > > refreshing > > the icons in the launcher. > > > > During uninstall, it'll remove the copy. > > > > By the way, we do .rpm and .deb, but also give instructions for users to > > extract the files if they want their own installation directory. > > > > The above .desktop support can be put in a script and added to the postinst > > > > and prerm scripts for rpm and deb. > > > > This makes things more automatic for the majority of our users (basically > > download-click-and-run). > > > > Clint > > > > > > Thanks for the information. Based on that, I wrote a script that is > bundled with the contents and when run, will generate the correct > .desktop file with the correct absolute paths needed and invoke > xdg-desktop-menu install. > > I noticed that the CPack tarball generator also generates a > self-extracting .sh ball. Is there anyway to hook into that to add a > postinst like stage so I can invoke my script? > You can copy CMake/Modules/CPack.STGZ_Header.sh.in, make your modifications, then set CPACK_STGZ_HEADER_FILE to point to it. Clint -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] CMake removes rpath from Linux binaries. How to stop
- Original Message - > I am trying to create a standalone build of our application on Linux. We are > currently building on a mix of Mint 17 and Ubuntu 14.04. I have been doing a > lot of reading about rpath, runpath and chrpath. The only way it would seem > to get this done is to adjust the rpath via the "chrpath" tool. The issue is > that during packaging, cmake is removing the rpath from the binaries which > kills the process of using chrpath. I have looked at the various *_RPATH* > cmake variables but none of the combinations seem to work correctly. CMake > always strips the rpath from the binaries. This is with a Qt5 application > which compiles against the Qt 5.4.1 version which is installed from the > Qt.io website. Have you tried only setting the INSTALL_RPATH property on the targets? Or setting the CMAKE_INSTALL_RPATH in your top level CMakeLists.txt file. For example: if (CMAKE_SYSTEM_NAME MATCHES "Linux" ) set (CMAKE_ INSTALL _RPATH "\$ORIGIN" ) endif () That alone should be enough to give you rpaths in the install tree. Clint -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] getting the rpath right on osx
- On Nov 2, 2015, at 2:26 AM, Boudewijn Rempt b...@valdyas.org wrote:
> I checked the manual and the blog post about rpath on osx, but I'm still
> confused, and still not getting it right...
>
> I build and installed Qt 5.6 alpha like this:
>
> ./configure -prefix /Users/boudewijnrempt/kf5/i
>
> Then I made a small test project, consisting of nothing but a main that links
> to
> QtCore.
>
> If I build that with qmake, with this .pro file:
>
> QT += core
> QT -= gui
> TARGET = rpathqmake
> CONFIG += console
> CONFIG -= app_bundle
> TEMPLATE = app
> SOURCES += main.cpp
>
> The r-path is set:
>
> Boudewijns-Mac-mini:test boudewijnrempt$ otool -L rpathqmake
> rpathqmake:
> @rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0,
> current
> version 5.6.0)
>
> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
> (compatibility version 1.0.0, current version 1.0.0)
> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility
> version 1.0.0, current version 275.0.0)
> /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
> 120.0.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
> 1213.0.0)
>
> Boudewijns-Mac-mini:test boudewijnrempt$ otool -L rpathqmake | grep -i rpath
> rpathqmake:
> @rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0,
> current
> version 5.6.0
Keep in mind, "otool -L" doesn't show rpaths.
@rpath/QtCore.framework/Versions/5/QtCore is not an rpath.
@rpath is a place holder where an rpath can be substituted.
Anytime you see "@rpath" what it means is that the dependent library wants to
be found using rpaths.
Use "otool -l" | grep -A2 LC_RPATH to see the rpaths.
>
> If I try a minimal cmakelists.txt, the rpath isn't set, I tried with and
> without
> all those RPATH related lines,
> they don't seem to make a difference. I'm using cmake 3.3.2.
>
> cmake_minimum_required(VERSION 2.8.12)
> cmake_policy(SET CMP0042 NEW)
> set(CMAKE_MACOSX_RPATH ON)
> SET(CMAKE_SKIP_BUILD_RPATH TRUE)
> SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
> SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
> set(REQUIRED_QT_VERSION 5.3.0)
> find_package(Qt5 ${REQUIRED_QT_VERSION} CONFIG REQUIRED Core)
> add_executable(rpathcmake main.cpp)
> target_link_libraries(rpathcmake Qt5::Core)
> install(TARGETS rpathcmake DESTINATION /Users/boudewijnrempt/kf5/i/bin)
If you remove
set(CMAKE_MACOSX_RPATH ON)
SET(CMAKE_SKIP_BUILD_RPATH TRUE)
SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
then, it would probably be a minimal example.
>
> Only adding something like this makes it work:
>
> set_target_properties(rpathcmake PROPERTIES INSTALL_RPATH
> "/Users/boudewijnrempt/kf5/i/lib")
>
> Which I'm pretty sure is something I don't want.
To fix the errors below, you actually to do something like this.
set_target_properties(rpathcmake PROPERTIES INSTALL_RPATH
"/Users/boudewijnrempt/kf5/i/lib")
What you probably want is to use a variable instead of an absolute path.
set_target_properties(rpathcmake PROPERTIES INSTALL_RPATH
"@loader_path/../lib")
That property along with MACOSX_RPATH, or the global property
CMAKE_MACOSX_RPATH are the 2 first variables you would set.
MACOSX_RPATH property on a target indicates that its install 'ID' contains
@rpath, and it wants to be found using rpaths. INSTALL_RPATH property is a
list of rpaths to help find dependencies which want to be found using rpaths.
>
> Boudewijns-Mac-mini:test boudewijnrempt$ make install
> [100%] Built target rpathcmake
> Install the project...
> -- Install configuration: ""
> -- Up-to-date: /Users/boudewijnrempt/kf5/i/bin/rpathcmake
> Boudewijns-Mac-mini:test boudewijnrempt$ otool -L
> /Users/boudewijnrempt/kf5/i/bin/rpathcmake
> /Users/boudewijnrempt/kf5/i/bin/rpathcmake:
> @rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0,
> current
> version 5.6.0)
> /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
> 120.0.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
> 1197.1.1)
> Boudewijns-Mac-mini:test boudewijnrempt$ ~/kf5/i/bin/rpathcmake
> dyld: Library not loaded: @rpath/QtCore.framework/Versions/5/QtCore
> Referenced from: /Users/boudewijnrempt/kf5/i/bin/rpathcmake
> Reason: image not found
> Trace/BPT trap: 5
> Boudewijns-Mac-mini:test boudewijnrempt$ otool -L
> /Users/boudewijnrempt/kf5/i/bin/rpathcmake
> /Users/boudewijnrempt/kf5/i/bin/rpathcmake:
> @rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0,
> current
> version 5.6.0)
> /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
> 120.0.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
> 1197.1.1)
>
> What should I do?
Set the INSTALL_RPATH target property.
Clint
--
Powered by www.kitware.com
Pleas
[CMake] autouic problem with Visual Studio
Hi, I'm trying out the autouic feature in Visual Studio, and I noticed that if I change a .ui file, the corresponding ui_*.h file is not regenerated when I hit the build button. I don't see this problem under Makefiles. For makefiles, it appears a phony target is used and "cmake -E cmake_autogen" is always run each time make is called. For visual studio, the build rule to execute "cmake -E cmake_autogen" has a list of dependencies. This list of dependencies includes all the files listed in a .qrc file, but none of the .ui files. If I right click on the file representing this build rule, and click "compile", it then runs "cmake -E cmake_autogen" and the ui_*.h files are incrementally updated (only those for which corresponding .ui files were changed). This appears to be a bug. The setup is different between the two, and perhaps the build rule under visual studio should list all the dependent .ui files. Is anyone else seeing this behavior? Thanks, Clint -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] CPack and PackageMaker
If you are interested, attached is some code I started a couple years ago but
never finished, nor did I do much testing.
Perhaps that'll help, or maybe you'll find a better way.
Clint
- On Dec 11, 2015, at 9:50 AM, Robert Bielik robert.bie...@dirac.se wrote:
> Dear Attila,
>
> Ok, been struggling getting an installation package to work with the
> pkgbuild/productbild tools, so I think I got the gist of what needs to
> be done, at least to get something going :)
>
> Regards
> /R
>
> Den 2015-12-11 kl. 17:47, skrev Attila Krasznahorkay:
>> Hi Robert,
>>
>> I'm afraid that the sad situation is that nobody has done this yet, or is
>> working on it at the moment.
>>
>> I'm absolutely sure that if you can help with this by any amount, that will
>> be
>> most welcome by the CMake developers. It will certainly be most welcome by
>> me,
>> as I've been disappointed by the lack of this support as well. (But
>> unfortunately can't spare the time to help out in writing this CPack
>> generator.)
>>
>> Cheers,
>> Attila
>>
>>> On 11 Dec 2015, at 17:44, Robert Bielik wrote:
>>>
>>> Really ? No one ? :)
>>>
>>> So it's ok to go ahead and start create a new one ? ;)
>>>
>>> Rgds,
>>> /R
>>>
>>> Den 2015-12-09 kl. 16:56, skrev Robert Bielik:
>>>> Mac OSX:
>>>>
>>>> Since PackageMaker has been deprecated by Apple, the new tools to use are
>>>> pkgbuild [1] and productbuild [2].
>>>>
>>>> Simple question: Is there any work being done by the CMake community on a
>>>> new OS
>>>> X CPack backend to support the above tools ?
>>>>
>>>> Regards
>>>> /Robert
>>>> [1]
>>>> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/pkgbuild.1.html
>>>> [2]
>>>> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/productbuild.1.html
>>>>
>>> --
>>>
>>> Powered by www.kitware.com
>>>
>>> Please keep messages on-topic and check the CMake FAQ at:
>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Kitware offers various services to support the CMake community. For more
>>> information on each offering, please visit:
>>>
>>> CMake Support: http://cmake.org/cmake/help/support.html
>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/cmake
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
commit a49e2b32e9ac1d2d486829c5ee4d8a399530875f
Author: Clinton Stimpson
Date: Sat Nov 2 10:24:53 2013 -0600
add product build generator.
diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt
index a4c982f..79dab75 100644
--- a/Source/CMakeLists.txt
+++ b/Source/CMakeLists.txt
@@ -632,6 +632,7 @@ if(APPLE)
CPack/cmCPackDragNDropGenerator.cxx
CPack/cmCPackOSXX11Generator.cxx
CPack/cmCPackPackageMakerGenerator.cxx
+CPack/cmCPackProductBuildGenerator.cxx
)
endif()
diff --git a/Source/CPack/cmCPackGeneratorFactory.cxx b/Source/CPack/cmCPackGeneratorFactory.cxx
index 94ca536..ed1821f 100644
--- a/Source/CPack/cmCPackGeneratorFactory.cxx
+++ b/Source/CPack/cmCPackGeneratorFactory.cxx
@@ -28,6 +28,7 @@
# include "cmCPackBundleGenerator.h"
# include "cmCPackPackageMakerGenerator.h"
# include "cmCPackOSXX11Generator.h"
+# include "cmCPackProductBuildGenerator.h"
#endif
#ifdef __CYGWIN__
@@ -139,6 +140,11 @@ cmCPackGeneratorFactory::cmCPackGeneratorFactory()
this->RegisterGenerator("OSXX11", "Mac OSX X11 bundle",
cm
Re: [CMake] fixup bundle vs Qy 5.5.1 and rpaths
It appears you need to add the directory(ies) in the Qt installation containing
the Qt libraries to your DIRS.
set( DIRS
${APP}/Contents/plugins/platforms
${QT_BINARY_DIR}
${QT_LIBRARY_DIR}
)
I think it should have been that way, even with Qt 5.3.
Clint
- On Dec 18, 2015, at 6:12 AM, Gregory Van Vooren
wrote:
> I have a project containing several applications (which are sub projects),
> each
> of which links against some Qt libraries which are built as dylibs, but are
> not
> part of the project. Qt libraries and headers are found using find-package
> which is working perfectly.
> I’m currently trying to switch from Qt 5.3.1 to Qt 5.5.1, but am experiencing
> problems with fixup_bundle on OS X (everything else seems to work fine).
> As far as I’ve gathered Qt has introduced support for rpaths between those two
> version and this seems to be the cause of my problems.
> Building a single application works and said application starts up correctly,
> but building the install target will give me the following output:
> -- fixup_bundle: preparing...
> --
> warning: cannot resolve item 'libQt5Core_debug.5.dylib'
> possible problems:
> need more directories?
> need to use InstallRequiredSystemLibraries?
> run in install tree instead of build tree?
> -- warning: gp_resolved_file_type non-absolute file 'libQt5Core_debug.5.dylib'
> returning type 'other' -- possibly incorrect
> --
> warning: cannot resolve item 'libQt5Core_debug.5.dylib'
> possible problems:
> need more directories?
> need to use InstallRequiredSystemLibraries?
> run in install tree instead of build tree?
> warning: target 'libQt5Core_debug.5.dylib' is not absolute...
> warning: target 'libQt5Core_debug.5.dylib' does not exist...
> CMake Error at
> /Applications/CMake.app/Contents/share/cmake-3.4/Modules/GetPrerequisites.cmake:800
> (message):
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/otool
> failed: 1
> error:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/otool:
> can't open file: libQt5Core_debug.5.dylib (No such file or directory)
> Call Stack (most recent call first):
> /Applications/CMake.app/Contents/share/cmake-3.4/Modules/GetPrerequisites.cmake:925
> (get_prerequisites)
> /Applications/CMake.app/Contents/share/cmake-3.4/Modules/BundleUtilities.cmake:555
> (get_prerequisites)
> /Applications/CMake.app/Contents/share/cmake-3.4/Modules/BundleUtilities.cmake:804
> (get_bundle_keys)
> someApplication/someApplication/cmake_install.cmake:115 (fixup_bundle)
> I’ll try to provide sufficient yet minimal information to pinpoint the root
> cause of the problem.
> In my top CMakeLists.txt I have the following:
> set (
> QT_REQUIRED_PACKAGES
> Core
> Gui
> Widgets
> )
> set( QT_ROOT_PATH "/usr/local/Qt-5.5.1" )
> set( QT_REQUIRED_PACKAGES ${QT_REQUIRED_PACKAGES} MacExtras )
> set(
> QT_PLUGINS_DIR
> "${QT_ROOT_PATH}/plugins"
> )
> set ( CMAKE_PREFIX_PATH ${CMAKE_PREFIX_PATH} "${QT_ROOT_PATH}/bin/" )
> FOREACH(QT_PACKAGE ${QT_REQUIRED_PACKAGES})
> set( QT_PACKAGE_WITH_PREFIX "Qt5${QT_PACKAGE}" )
> set( "${QT_PACKAGE_WITH_PREFIX}_DIR"
> "${QT_ROOT_PATH}/lib/cmake/${QT_PACKAGE_WITH_PREFIX}" )
> find_package( "${QT_PACKAGE_WITH_PREFIX}" REQUIRED )
> include_directories( ${${QT_PACKAGE_WITH_PREFIX}_INCLUDE_DIRS} )
> set_target_properties( "Qt5::${QT_PACKAGE}" PROPERTIES
> MAP_IMPORTED_CONFIG_DEBUG
> "DEBUG")
> set_target_properties( "Qt5::${QT_PACKAGE}" PROPERTIES
> MAP_IMPORTED_CONFIG_RELEASE "RELEASE")
> set_target_properties( "Qt5::${QT_PACKAGE}" PROPERTIES
> MAP_IMPORTED_CONFIG_RELWITHDEBINFO "RELEASE")
> ENDFOREACH(QT_PACKAGE)
> add_definitions( ${QT_DEFINITIONS} )
> set( CMAKE_INSTALL_PREFIX ${CMAKE_CURRENT_BINARY_DIR} )
> set( CMAKE_MACOSX_RPATH “" )
> set_property( GLOBAL PROPERTY USE_FOLDERS ON )
> add_subdirectory( someApplication )
> in the someApplication CMakeLists.txt I have the following:
> set(
> someApplication_Qt_LIBRARIES
> ${Qt5Core_LIBRARIES}
> ${Qt5Widgets_LIBRARIES}
> )
> set_target_properties( someApplication PROPERTIES INSTALL_RPATH
> "${QT_ROOT_PATH}/lib" )
> foreach( OUTPUTCONFIG ${CMAKE_CONFIGURATION_TYPES} )
> install( TARGETS someApplication DESTINATION bin/${OUTPUTCONFIG}
> CONFIGURATIONS
> ${OUTPUTCONFIG} )
> endforeach()
> add_custom_command( TARGET someApplication POST_BUILD COMMAND mkdir -p
> ${CMAKE_INSTALL_PREFIX}/LocalizationTools/someApplication/Debug/plugins/platforms/
> )
> add_custom_command( TARGET someApplication POST_BUILD COMMAND cp -Rf
> "${QT_PLUGINS_DIR}/platforms/libqcocoa_debug.dylib"
> ${CMAKE_INSTALL_PREFIX}/LocalizationTools/someApplication/Debug/plugins/platforms/
> )
> add_custom_command( TARGET someApplication POST_BUILD COMMAND mkdir -p
> ${CMAKE_INSTALL_PREFIX}/LocalizationTools/someApplication/Release/plugins/platforms/
> )
> add_custom_command( TARGET someApplication POST_BUILD COMMAND cp -Rf
> "${QT_PLUGINS_DIR}/platforms/libqcocoa.dylib"
> ${CMAKE_INSTALL_PREFIX}/
Re: [CMake] still having rpath problems on osx
On Dec 21, 2015 12:26 PM, Boudewijn Rempt wrote: > > I'm still having rpath problems when creating libraries on OSX... And I'm not > sure what's going on here. Here's the output for a single library: > > otool -L ../i/lib/libkritaimage.dylib > ../i/lib/libkritaimage.dylib: > /Users/boud/dev/i/lib/libkritaimage.15.dylib (compatibility version > 15.0.0, current version 15.0.0) > /Users/boud/dev/i/lib/libkritawidgets.15.dylib (compatibility version > 15.0.0, current version 15.0.0) > /Users/boud/dev/i/lib/libkritapsd.15.dylib (compatibility version > 15.0.0, current version 15.0.0) > libboost_system.dylib (compatibility version 0.0.0, current version > 0.0.0) > @rpath/libImath.12.dylib (compatibility version 12.0.0, current version > 12.0.0) > @rpath/libIlmImf.22.dylib (compatibility version 22.0.0, current version > 22.0.0) > @rpath/libIex.12.dylib (compatibility version 12.0.0, current version > 12.0.0) > @rpath/libHalf.12.dylib (compatibility version 12.0.0, current version > 12.0.0) > @rpath/libIlmThread.12.dylib (compatibility version 12.0.0, current > version 12.0.0) > /Users/boud/dev/i/lib/libfftw3.3.dylib (compatibility version 8.0.0, > current version 8.4.0) > @rpath/libgsl.dylib (compatibility version 0.0.0, current version 0.0.0) > /Users/boud/dev/i/lib/libkritaflake.15.dylib (compatibility version > 15.0.0, current version 15.0.0) > /Users/boud/dev/i/lib/libkritaodf.15.dylib (compatibility version > 15.0.0, current version 15.0.0) > /Users/boud/dev/i/lib/libkritaversion.15.dylib (compatibility version > 15.0.0, current version 15.0.0) > /Users/boud/dev/i/lib/libkritastore.15.dylib (compatibility version > 15.0.0, current version 15.0.0) > /Users/boud/dev/i/lib/libKF5Archive.5.dylib (compatibility version > 5.0.0, current version 5.17.0) > /Users/boud/dev/i/lib/libkritaundo2.15.dylib (compatibility version > 15.0.0, current version 15.0.0) > /Users/boud/dev/i/lib/libkritawidgetutils.15.dylib (compatibility > version 15.0.0, current version 15.0.0) > /Users/boud/dev/i/lib/libKF5ItemViews.5.dylib (compatibility version > 5.0.0, current version 5.17.0) > @rpath/QtPrintSupport.framework/Versions/5/QtPrintSupport (compatibility > version 5.6.0, current version 5.6.0) > /Users/boud/dev/i/lib/libKF5GuiAddons.5.dylib (compatibility version > 5.0.0, current version 5.17.0) > /Users/boud/dev/i/lib/libKF5Completion.5.dylib (compatibility version > 5.0.0, current version 5.17.0) > /Users/boud/dev/i/lib/libKF5ConfigGui.5.dylib (compatibility version > 5.0.0, current version 5.17.0) > /Users/boud/dev/i/lib/libKF5WidgetsAddons.5.dylib (compatibility version > 5.0.0, current version 5.17.0) > /Users/boud/dev/i/lib/libkritaglobal.15.dylib (compatibility version > 15.0.0, current version 15.0.0) > @rpath/QtConcurrent.framework/Versions/5/QtConcurrent (compatibility > version 5.6.0, current version 5.6.0) > @rpath/QtWidgets.framework/Versions/5/QtWidgets (compatibility version > 5.6.0, current version 5.6.0) > /Users/boud/dev/i/lib/libkritapigment.15.dylib (compatibility version > 15.0.0, current version 15.0.0) > @rpath/QtGui.framework/Versions/5/QtGui (compatibility version 5.6.0, > current version 5.6.0) > @rpath/QtXml.framework/Versions/5/QtXml (compatibility version 5.6.0, > current version 5.6.0) > /Users/boud/dev/i/lib/libkritaplugin.15.dylib (compatibility version > 15.0.0, current version 15.0.0) > /Users/boud/dev/i/lib/libKF5CoreAddons.5.dylib (compatibility version > 5.0.0, current version 5.17.0) > /Users/boud/dev/i/lib/libKF5ConfigCore.5.dylib (compatibility version > 5.0.0, current version 5.17.0) > /Users/boud/dev/i/lib/libKF5I18n.5.dylib (compatibility version 5.0.0, > current version 5.17.0) > @rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0, > current version 5.6.0) > /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version > 120.1.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version > 1225.1.1) > > All libraries I link to are built. Some come with a cmake build system, some > with an automake build system, boost with something else altogether... But I > wouldn't have expected the way a library is built to make a difference for > the link lines in the library that links to the other library. You may not expect this, but this is how it works. @rpath is a way for a library to say, "i want to be found using rpaths" > > Obviously, > libboost_system.dylib (compatibility version 0.0.0, current version > 0.0.0) > is wrong -- it's got neither an @rpath, nor a full path. If it is wrong, you need to fix it in boost, or fix it with install_name_tool before linking against it. > > I'm not sure even why some libraries are linked to with @rpath and others > with a > full p
Re: [CMake] still having rpath problems on osxZ
- On Dec 31, 2015, at 1:41 AM, Boudewijn Rempt b...@valdyas.org wrote: > I think I've finally figured out why I didn't get the results the cmake > documentation suggested I should be getting... It's the extra-cmake-modules > that I use, Krita being a KDE application. With these settings: > > set(KDE_SKIP_RPATH_SETTINGS 1) > set(CMAKE_MACOSX_RPATH 1) > set(BUILD_WITH_INSTALL_RPATH 1) > > My libraries are built with an @rpath id, instead of an absolute path id. Now > only the executable needs to have its rpath set correctly after install and > after making a bundle, and all libraries are found and all plugins find the > libraries, too. > > Without KDE_SKIP_RPATH_SETTINGS, everything gets set to full, absolute paths > on > doing a make install. That might make sense on Linux, I guess... But no wonder > that I was confused all the time. > > So, to check that I really understand it: > > On OSX, every library has an id. That id can be > /abs/o/lute/path/to/library.dylib or library.dylib or @rpath/library.dylib. Yes, there is an id. @executable_path and @loader_path are a couple other that can used in addition to the list you provided. > > The exectutable has a bunch of paths where it can look for libraries, and the > path + library.dylib has to match the library id. I'm not sure what you mean by that. The library id is used only at link time, and not at runtime. There is no matching to the library id at runtime. At link time, the id is taken as-is and put into the executable as a dependency. If you are familiar with SONAME on ELF platforms, think of the id in a dylib being similar. > > so, if the executable has > > @path = ../lib;../Frameworks > > and links to > > @path/library.dylib > > and a library with that id is in ../lib (or ../Frameworks) from the > executable's > location, everything will be fine. I think you have the idea there. But just in case, let me enumerate how the runtime loader looks at these: 1. an exectuable with a /absolute/path/to/library.dylib dependency The library is searched for at the absolute path. If not found, library.dylib is searched in /usr/local/lib:/lib:/usr/lib environment variables such as DYLD_LIBRARY_PATH can override search locations. 2. an executable with a library.dylib dependency library.dylib is searched in /usr/local/lib:/lib:/usr/lib environment variables such as DYLD_LIBRARY_PATH can override search locations. 3. a binary with a @executable_path/library.dylib dependency The library is located in the same directory as the executable If the binary is another shared library, whether in another directory or not, library.dylib will be searched for in the same directory as the executable. If not found, a search is made in /usr/local/lib:/lib:/usr/lib environment variables such as DYLD_LIBRARY_PATH can override search locations. both exectuables and libraries can have @executable_path 3. a binary with @loader_path/library.dylib dependency the library is located in the same directory as the binary (may be the same directory as the executable or not). If not found, a search is made in /usr/local/lib:/lib:/usr/lib environment variables such as DYLD_LIBRARY_PATH can override search locations. 4. a binary with @rpath/library.dylib dependency the binary can also have a list of rpaths embedded. Each rpath is used to replace the "@rpath" portion of the dependency to locate the dependency. For flexibility, rpaths may contain absolute paths, @executable_path or @loader_path. For example, a binary can have an rpath @loader_path/../lib, and a dependency @rpath/library.dylib. After substitution, you have: @loader_path/../lib/library.dylib. With that, go see how @loader_path is handled. If not found, a search is made in /usr/local/lib:/lib:/usr/lib environment variables such as DYLD_LIBRARY_PATH can override search locations. > > Which makes it easiest for me, I guess to have @rpath in the id for every > library, and on make install set the exectables' rpath to where I install the > libraries to, and on creating the bundle update the rpaths in the executable > to > the Frameworks folder. The only thing that won't work is running unittests > without installing, but that's not a big problem, for me... > I also find @rpath easiest for me. I make sure all my 3rd party non-system dependencies use @rpath. In my case, these libraries are built once and shared among multiple developers. Using @rpath also allows multiple developers to place these libraries in their own home directories, and CMake's automatic rpath handling helps simplify things. Then when I build my bundles or create packages, I don't need to do any "install_name_tool -change" work. I do set the rpaths on exectuables during install, which is nearly identical to what I do on Linux. I'm curious why the unit tests do not work. Mine work just fine for me. If you have a setting to skip rpaths in the build tree, I guess th
Re: [CMake] CMAKE_INSTALL_RPATH_USE_LINK_PATH is broken?
On Jan 8, 2016 8:16 PM, Elizabeth Fischer wrote: > > Hello, > > I'm using cmake 3.4.1. I'm trying to compile libraries & executables with an > RPATH. To that end, I use the following settings: >> >> >> SET(CMAKE_SKIP_BUILD_RPATH FALSE) >> SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE) >> SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE) > > > I then link in a lot of libraries. However, ONLY ONE of the libraries gets > picked up to be used in the RPATH sent to the linker. I can manually set > CMAKE_INSTALL_RPATH (that works). But CMAKE_INSTALL_RPATH_USE_LINK_PATH > seems to be broken. > > Interestingly, the one library it's willing to auto-generate an RPATH for is > the same library, whether it comes first or last in the link command line. > The link command generated by CMake is shown below; it's clear that many > libraries are being linked in, but only one rpath is being generated. Did you check that the libraries you are linking against have an install name starting with @rpath? For example, otool -D /Users/rpfische/eb/software/netCDF/4.3.2-mpgompi-4.9.3/lib/libnetcdf.dylib CMake will only consider adding an rpath for a library if the install name starts with @rpath. Clint > > HELP? > --- Elizabeth > >> [ 30%] Linking CXX executable test_array >> >> cd /Users/rpfische/git/spsparse/build/test && >> /Users/rpfische/macports/mpgompi-4.9.3/bin/cmake -E cmake_link_script >> CMakeFiles/test_array.dir/link.txt --verbose=1 >> >> /Users/rpfische/macports/mpgompi-4.9.3/bin/g++ -g -Wl,-search_paths_first >> -Wl,-headerpad_max_install_names CMakeFiles/test_array.dir/test_array.cpp.o >> -o test_array >> /Users/rpfische/eb/software/gtest/1.7.0-GCC-4.9.3/lib/libgtest.a >> /Users/rpfische/eb/software/gtest/1.7.0-GCC-4.9.3/lib/libgtest_main.a >> /Users/rpfische/eb/software/netCDF/4.3.2-mpgompi-4.9.3/lib/libnetcdf.dylib >> /Users/rpfische/eb/software/netCDF-C++4/ecdf914-mpgompi-4.9.3/lib/libnetcdf-cxx4.dylib >> /Users/rpfische/eb/software/ibmisc/devel/lib/libibmisc.dylib >> ../slib/libspsparse.dylib >> /Users/rpfische/eb/software/netCDF/4.3.2-mpgompi-4.9.3/lib/libnetcdf.dylib >> /Users/rpfische/eb/software/netCDF-C++4/ecdf914-mpgompi-4.9.3/lib/libnetcdf-cxx4.dylib >> /Users/rpfische/eb/software/ibmisc/devel/lib/libibmisc.dylib >> -Wl,-rpath,/Users/rpfische/eb/software/ibmisc/devel/lib -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] CPack: Packaging debug and release configurations in a single zip
Does that result in building the code 3 times?
And why would you need to repeat the install directives?
I've attached a CMakeLists.txt file for an example project that works for me
without repeating install directives.
Clint
- Original Message -
> Here's a follow-up.
> I was unable to get Jean-Christophes modification of Ansis' solution working.
> (I definitely did not want to repeat the install directives in this rather
> large project.) The " -DCMAKE_BUILD_TYPE" lines don't really accomplish
> anything when building with Visual Studio. I was making progress but
> ultimately gave up. Here is where I stopped.
> #
> include(ExternalProject)
> ExternalProject_Add(MyProjectDebug
> PREFIX Debug
> SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}
> CMAKE_ARGS -G ${CMAKE_GENERATOR} -D CMAKE_BUILD_TYPE=Debug -D
> CPACK_BUILD_CONFIG=Debug
> BUILD_COMMAND "${CMAKE_COMMAND}" --build
> ${CMAKE_BINARY_DIR}/Debug/src/MyProjectDebug-build --config Debug
> )
> ExternalProject_Add(MyProjectRelease
> PREFIX Release
> SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}
> CMAKE_ARGS -G ${CMAKE_GENERATOR} -D CMAKE_BUILD_TYPE=Release -D
> CPACK_BUILD_CONFIG=Release
> BUILD_COMMAND "${CMAKE_COMMAND}" --build
> ${CMAKE_BINARY_DIR}/Release/src/MyProjectRelease-build --config Release
> )
> set(CPACK_INSTALL_CMAKE_PROJECTS
> "${CMAKE_BINARY_DIR}/Debug/src/MyProjectDebug-build;MyProject;ALL;/"
> "${CMAKE_BINARY_DIR}/Release/src/MyProjectRelease-build;MyProject;ALL;/"
> )
> include(CPack)
> #
> At this point, the debug build would build in the debug tree and the release
> build in the release tree. All is well to that point. However, when I would
> attempt to use CPack with no -C option it would attempt to package Debug
> from the Release tree. When I would attempt to use CPack with a -C option,
> it would fail on one or the other (whichever one I did not specify).
> I tried a slight fork of the above using the NMake generator instead of the
> Visual Studio 10 generator but still ran into some issues local to our CMake
> files. I may try to resolve that next, but if anybody has any hints of where
> go from here that would be appreciated.
> Frankly it seems to me that we should be able to package multiple configs
> without any of this extra work.
> On Fri, Feb 8, 2013 at 2:50 AM, Yngve Inntjore Levinsen <
> yngve.levin...@gmail.com > wrote:
> > On 7/2/13 7:54 PM, Patrick Johnmeyer wrote:
>
> > > On Thu, Feb 7, 2013 at 12:41 PM, Yngve Inntjore Levinsen <
> > > yngve.levin...@gmail.com > wrote:
> >
>
> > > > I think you are fighting the tool in any case, because you are asking
> > > > to
> > > > build multiple configurations in one build folder (?). Normally you
> > > > would
> > > > create one build folder per configuration.. Which I guess is what you
> > > > are
> > > > doing today.
> > >
> >
>
> > > No, the Visual Studio generator is not a " single-configuration
> > > generator"
> > > .
> > > all configurations are bundled into the single generated solution file.
> > > This
> > > is the standard behavior of CMake under "basic" usage.
> >
>
> > > Your solution using ExternalProject looks promising, though, I will try
> > > this
> > > out. Thanks!
> >
>
> > Aha, I have mostly used the Makefile generator, and never VS, so I didn't
> > know that. I agree, the externalproject trick proposed by Ansis sounds
> > better. Good luck!
>
> > Cheers,
>
> > Yngve
>
> --
> Powered by www.kitware.com
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmakecmake_minimum_required(VERSION 2.8)
project(myproject)
option(OPTION_XYZ "my option" OFF)
set(CMAKE_DEBUG_POSTFIX _d)
add_library(foo SHARED foo.cpp foo.hpp)
install(TARGETS foo DESTINATION lib)
option(CPACK_MULTICONFIG_PACKAGE "Enable creating a multi-config package with both debug and release (doubles compile time)" OFF)
if(CPACK_MULTICONFIG_PACKAGE)
# If using makefiles, pick the other of Release/Debug as the build type.
# If using visual studio with the configuration including both debug and release,
# pick debug for the other configuration, as this one's cpack files will default to release.
# The cpack user should not use the -C flag
if(CMAKE_CONFIGURATION_TYPES)
if(CMAKE_CONFIGURATION_TYPES MATCHES "([Rr][Ee][Ll][Ee][Aa][Ss][Ee])")
set(other_config_type "Debug")
else()
set(other_config_type "Release")
endif()
set(other_config_flag "CMAKE_CONFIGURATION_TYPES:STRING=${other_config_type}")
else()
if(NOT CMAKE_BUILD_TYPE)
message(SEND_ERROR "You must set CMAKE_BUILD_TYPE to Debug or Release")
endif(NOT CMAKE_BUILD_TYPE)
if(CMAKE_BUILD_TYPE MATCHES "([Rr][Ee][Ll][Ee][Aa][Ss][Ee])")
set(other_config_type "Debug")
else()
set(other_config_type "Release")
Re: [CMake] how to compile as 32bit on a 64bit Linux host ?
Or simply specify -m32 at the first configure CFLAGS=-m32 CXXFLAGS=-m32 cmake ../src find_library() works correctly if you do that, and it automatically detects if the 32 bit libraries are in /usr/lib32 or /usr/lib. Clint - Original Message - > Hello, > > On 15/02/13 15:41, Martin Koller wrote: > > I'm just not sure if it is enough to change the compiler flags or if > > there is more to change (paths etc.) > This is why I prefer toolchain files over adding an option inside the > CMakeLists.txt files. On some systems you probably also want to change > the search path for libraries in particular (often /usr/lib32 instead of > /usr/lib), so that the find_package() commands and similar does not find > the incompatible 64 bit libraries. > > In our system we both have an option to "force 32 bit" (which basically > just adds -m32 to compile flags), and I have a toolchain file (which > corresponds to my stackoverflow answer). I find the toolchain file to be > more accurate/flexible to get correct setup. > > In addition to the three lines you might also want to set paths (I do > not need that on my system for my projects), something along the lines of: > > set(CMAKE_FIND_ROOT_PATH /usr/lib32) > set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) > set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) > set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) > > Cheers, > Yngve > -- > > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake > -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] rpmbuild architecture
I'm trying to build an i686 RPM package on a x86_64 Linux machine. I have a set(CPACK_RPM_PACKAGE_ARCHITECTURE i686) but I get an error at CPack time: error: No compatible architectures found for build I can get it to work if I also use setarch when calling rpmbuild giving it the CPack generated RPM spec file, like so: setarch i686 rpmbuild --bb --define "_topdir $PWD" --buildroot $PWD/ SPECS/myspec.spec Doing the equivalent for a Debian package seemed to work by simply setting set(CPACK_DEBIAN_PACKAGE_ARCHITECTURE i386) Is there some way to make this work automatically within cpack? Thanks, Clint -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] INSTALL_INTERFACE question
I'm playing with some of the new cmake 2.8.11 features and an example I saw had
this:
set_property(TARGET foo PROPERTY
INTERFACE_INCLUDE_DIRECTORIES
"$"
"$"
)
I can see it put the expanded version of "${CMAKE_INSTALL_PREFIX}/include" in
my export file, but I want it to be relocatable. For example, if I use the
CPack ZIP generator, the files can be unzipped anywhere.
If I replace it with "$" , it complains about it
being a relative path.
Why is a relative path disallowed for INSTALL_INTERFACE? Should that be
figured out for me? Maybe it could put ${_IMPORT_PREFIX} in for me if it was a
relative path.
Clint
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
