Re: [cmake-developers] Preparing for 2.8.11-rc1
On 3/7/2013 5:13 PM, Brad King wrote: On 03/07/2013 04:09 PM, Alexander Neundorf wrote: IOW: without this fix cmake's exported target files are non-working on usr- move systems if installed into one of the affected directories. That's IMO a blocker. It's no worse than 2.8.10. Whatever fix you produce can be backported into whatever version those distros have. I apologize for the tone in my last couple responses to you in this thread. This is Much Ado About Nothing as the change isn't hard: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0c727b90 For completeness I responded in the original thread so please follow up there if you have any feedback. -Brad -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Qt 4 and 5 on the same system - qmake binary name priority
Hi, I notice that Arch has already patched this, but CMake master as of aa027af9 still finds /usr/bin/qmake when a /usr/bin/qmake-qt4 is available. This bug is reported here, http://public.kitware.com/Bug/view.php?id=13985 Is there any issue with changing the order so that if qmake-qt4 is found that is used preferentially over qmake which it seems will tend to be the Qt 5 qmake? Stephen mentions qtchooser but it isn't clear how relevant that is to making the find module prefer a qt4 specific suffix if one is found. I didn't look at the proposed patch that closely, but would like to understand any constraints on changing the binary name search order before proposing anything. Thanks, Marcus -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Qt 4 and 5 on the same system - qmake binary name priority
Its not as simple as changing the order. If I have my own build of Qt4, and if FindQt4.cmake had this: find_program(QT_QMAKE_EXECUTABLE NAMES qmake4 qmake-qt4 qmake-mac qmake ...) and I try to use my build of Qt CMAKE_PREFIX_PATH=/home/me/qt/qt-4.7.2 cmake ../ It finds /usr/bin/qmake-qt4 instead, because it searched for qmake-qt4 in all possible paths before searching for qmake. Currently, I think we need to keep qmake first. The proposed patch does improve the situation by making a separate find_program() call for each executable name. It also verifies the results of each find_program(). Clint On Friday, March 08, 2013 02:35:53 PM Marcus D. Hanwell wrote: Hi, I notice that Arch has already patched this, but CMake master as of aa027af9 still finds /usr/bin/qmake when a /usr/bin/qmake-qt4 is available. This bug is reported here, http://public.kitware.com/Bug/view.php?id=13985 Is there any issue with changing the order so that if qmake-qt4 is found that is used preferentially over qmake which it seems will tend to be the Qt 5 qmake? Stephen mentions qtchooser but it isn't clear how relevant that is to making the find module prefer a qt4 specific suffix if one is found. I didn't look at the proposed patch that closely, but would like to understand any constraints on changing the binary name search order before proposing anything. Thanks, Marcus -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] FindPackageCheckArchLinuxSymlinks branch on stage
On Friday 08 March 2013, Brad King wrote: On 1/25/2013 8:54 AM, Brad King wrote: On 01/25/2013 05:14 AM, Stephen Kelly wrote: Are INSTALL(EXPORT)ed files affected at all by this? Do they need to be? Yes, since they compute paths relative to their location in order to be relocatable. The code that generates them may need to be made aware of this. Please try out this change: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0c727b90 Looks good, will give it a try. I haven't checked yet whether there are any issues with cpack, since it has two different modes, a DESTDIR one and another one. I will have a look. Thanks :-) Alex -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Qt 4 and 5 on the same system - qmake binary name priority
On Fri, Mar 8, 2013 at 2:52 PM, Clinton Stimpson clin...@elemtech.com wrote: On Friday, March 08, 2013 02:35:53 PM Marcus D. Hanwell wrote: I notice that Arch has already patched this, but CMake master as of aa027af9 still finds /usr/bin/qmake when a /usr/bin/qmake-qt4 is available. This bug is reported here, http://public.kitware.com/Bug/view.php?id=13985 Is there any issue with changing the order so that if qmake-qt4 is found that is used preferentially over qmake which it seems will tend to be the Qt 5 qmake? Stephen mentions qtchooser but it isn't clear how relevant that is to making the find module prefer a qt4 specific suffix if one is found. I didn't look at the proposed patch that closely, but would like to understand any constraints on changing the binary name search order before proposing anything. Its not as simple as changing the order. If I have my own build of Qt4, and if FindQt4.cmake had this: find_program(QT_QMAKE_EXECUTABLE NAMES qmake4 qmake-qt4 qmake-mac qmake ...) and I try to use my build of Qt CMAKE_PREFIX_PATH=/home/me/qt/qt-4.7.2 cmake ../ It finds /usr/bin/qmake-qt4 instead, because it searched for qmake-qt4 in all possible paths before searching for qmake. Currently, I think we need to keep qmake first. The proposed patch does improve the situation by making a separate find_program() call for each executable name. It also verifies the results of each find_program(). Yeah, I didn't notice that (and hadn't thought about interaction with prefix path). It is a shame upstream couldn't agree on alternative names for the Qt 5 versions so that a consistent scheme could be used across distros. I can of course specify the full qmake path and all is well (or use the Arch patched FindQt4 module). What made me think this might work is all the subsequent calls for QT_*_EXECUTABLE but now I notice they use QT_BINARY_DIR. Thanks, Marcus -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0013992]: Source files with same name not building for VS 2010
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13992 == Reported By:toby_toby_toby Assigned To: == Project:CMake Issue ID: 13992 Category: (No Category) Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2013-03-08 17:14 EST Last Modified: 2013-03-08 17:14 EST == Summary:Source files with same name not building for VS 2010 Description: Project has 2 files with the same name, but different directories. VS2010 project unbuildable in that case. Steps to Reproduce: 1. configure and generate attached archive for VS2010 2. try build source.cpp - you should get this: badmake\subdirectory\source.cpp : fatal error C1083: Cannot open compiler generated file: 'project.dir\Debug\/subdirectory/source.cpp.obj': No such file or directory 3. now open generated vsproj in text editor and remove ObjectFileName from this: ItemGroup ClCompile Include=..\badmake\source.cpp ObjectFileName$(IntDir)/source.cpp.obj/ObjectFileName /ClCompile ClCompile Include=..\badmake\subdirectory\source.cpp ObjectFileName$(IntDir)/subdirectory/source.cpp.obj/ObjectFileName /ClCompile /ItemGroup and you will get this ClCompile Include=..\badmake\source.cpp / ClCompile Include=..\badmake\subdirectory\source.cpp / 4. reload project is VS, it's buildable now! == Issue History Date ModifiedUsername FieldChange == 2013-03-08 17:14 toby_toby_toby New Issue 2013-03-08 17:14 toby_toby_toby File Added: badmake.zip == -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0013995]: Builtin automoc doesn't automatically include system include path.
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=13995 == Reported By:Yichao Yu Assigned To: == Project:CMake Issue ID: 13995 Category: CMake Reproducibility:always Severity: major Priority: urgent Status: new == Date Submitted: 2013-03-09 00:42 EST Last Modified: 2013-03-09 00:42 EST == Summary:Builtin automoc doesn't automatically include system include path. Description: When qt is not installed in /usr/include (e.g. installed in /usr/include/qt4 instead), which is the default system include dir, the moc command line generated by builtin automoc doesn't have -I/usr/include argument, even if it has been explicitly added as include dir by include_directories, causing moc not able to find headers installed in the system include dir. Since this is the path the compiler will search anyway (unless using some special switch to turn off maybe?), moc should also search in this(these) path(s), especially when a dependency library has headers installed in it and therefore had added it explicitly. Since moc may has no idea what exactly the system include dir is (it's not gcc anyway) not to mention whether it has been explicitly added using include_directories in cmake, while cmake has access to these info, cmake should pass these dir as command line arguments (may put them at the end though). Steps to Reproduce: 1. Install qt's header in /usr/include/qt4 (so that qt4' qmake -query QT_INSTALL_HEADERS gives /usr/include/qt4) (just as what is done in archlinux's package). 2. Install phonon from git, which has headers installed in /usr/include/phonon and require /usr/include to be in the include path and also uses cmake's builtin automoc for newer cmake in it's git version. 3. Try compiling phonon-vlc from git, using make VERBOSE=1, error will be reported causing by not being able to find the definition of an interface which is actually defined in one of the headers in /usr/include/phonon (which is actually included by that header using #include phonon/**.h), the command line shows that -I/usr/include is not in the command line argument and strace the command line also shows the correct path is not searched. Adding -I/usr/include to command line argument works well. Additional Information: the automoc package works perfect. == Issue History Date ModifiedUsername FieldChange == 2013-03-09 00:42 Yichao Yu New Issue == -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
