Re: [cmake-developers] CMake master, Qt dialog and Qt4/5 installed has problems
Marcus D. Hanwell wrote: Hi, I was updating my machine earlier today, and wanted to build the latest CMake master (00ef90). I am using Arch Linux with Qt 4 and Qt 5 installed. If I compile with qmake-qt4 then I see the following compile failure, [ 88%] Generating qrc_CMakeSetup.cpp /bin/sh: //bin/rcc: No such file or directory make[2]: *** [Source/QtDialog/qrc_CMakeSetup.cpp] Error 127 make[1]: *** [Source/QtDialog/CMakeFiles/cmake-gui.dir/all] Error 2 make: *** [all] Error 2 This is the usr-move problem specific to arch and fedora. The problem is presumably that arch packages Qt 5.0.1. Qt 5.0.2 should resolve the problem (I expect it will be released within two weeks). Feel free to test that or feel free to cherry-pick 7ac58d1ff0815566ba1de09519299b5119e5ee91 and b9c1593435db3ed44e23c23dc19f22d7a68d7b01 from qtbase.git. Thanks, Steve. -- 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] CMake master, Qt dialog and Qt4/5 installed has problems
Stephen Kelly wrote: Marcus D. Hanwell wrote: Hi, I was updating my machine earlier today, and wanted to build the latest CMake master (00ef90). I am using Arch Linux with Qt 4 and Qt 5 installed. If I compile with qmake-qt4 then I see the following compile failure, Please also try the workaround-usr-move-qt5 branch on stage. Thanks, Steve. -- 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] ninja enforces explicit dependencies before order-only
On 02.04.2013 15:19, Brad King wrote:
Hi Peter,
We've come across a case where the Makefile, VS, and Xcode generators
work but Ninja does not::
cmake_minimum_required(VERSION 2.8.10)
project(DependSideEffect C)
add_library(A a.c)
add_custom_command(
TARGET A POST_BUILD
COMMAND cp ${CMAKE_CURRENT_SOURCE_DIR}/a.c a.txt
)
add_custom_command(
OUTPUT b.txt
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/a.txt
COMMAND cp a.txt b.txt
)
add_custom_target(B ALL DEPENDS b.txt)
add_dependencies(B A)
CMake's rule for target-level dependencies is that A must be up to
date before the build system evaluates the rules of B.
Building with Ninja fails with::
ninja: error: 'a.txt', needed by 'b.txt', missing and no known rule to make it
Relevant portions of build.ninja::
build libA.a: C_STATIC_LIBRARY_LINKER CMakeFiles/A.dir/a.c.o
POST_BUILD = cd .../build cp .../a.c a.txt
...
build b.txt: CUSTOM_COMMAND a.txt || libA.a
COMMAND = cd .../build cp a.txt b.txt
...
The rule for b.txt has an order-only dependency on libA.a and
an explicit dependency on a.txt. Ninja does not wait for the
order-only dependencies to be up to date before complaining that
the explicit dependency is missing.
Can ninja be taught to wait for order-only dependencies to be up to
date to see if they produce any of the explicit dependencies as
a side effect? Is there another way to do this in CMake's Ninja gen?
Thanks,
-Brad
In build.ninja is no rule for coping a.c to a.txt at all.
Seems support for add_custom_command(TARGET) is missing or broken.
Could you open a ticket and assign to me?
Peter
--
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 0014060]: FindGLUT puts NOTFOUND in GLUT_LIBRARIES
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14060
==
Reported By:Marcel Loose
Assigned To:
==
Project:CMake
Issue ID: 14060
Category: Modules
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2013-04-04 08:16 EDT
Last Modified: 2013-04-04 08:16 EDT
==
Summary:FindGLUT puts NOTFOUND in GLUT_LIBRARIES
Description:
FindGLUT puts GLUT_Xmu_LIBRARY-NOTFOUND;GLUT_Xi_LIBRARY-NOTFOUND in the variable
GLUT_LIBRARIES, when GLUT_FOUND is TRUE.
This causes CMake to bail out with the following error:
CMake Error: The following variables are used in this project, but they are set
to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake
files:
GLUT_Xi_LIBRARY (ADVANCED)
linked by target foo in directory /home/marcel/temp/cmake/findglut-bug
GLUT_Xmu_LIBRARY (ADVANCED)
linked by target foo in directory /home/marcel/temp/cmake/findglut-bug
Steps to Reproduce:
1. Create a CMakeLists.txt file that contains the following:
cmake_minimum_required(VERSION 2.8)
project(FindGLUT_Bug C)
find_package(GLUT)
if(GLUT_FOUND)
add_executable(foo foo.c)
target_link_libraries(foo ${GLUT_LIBRARIES})
endif()
2. Create a (empty) file foo.c
3. Run cmake
Additional Information:
This bug is also present in cmake 2.8.9. Older versions of cmake (e.g. 2.8.0)
set GLUT_FOUND to FALSE, which is probably also not what you'd want, because if
I remove the NOTFOUND entries from GLUT_LIBRARIES, everything works fine.
Workaround:
set(_glut_libraries)
foreach(_lib ${GLUT_LIBRARIES})
if(_lib)
list(APPEND _glut_libraries ${_lib})
endif()
endforeach()
set(GLUT_LIBRARIES ${_glut_libraries})
==
Issue History
Date ModifiedUsername FieldChange
==
2013-04-04 08:16 Marcel Loose 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
Re: [cmake-developers] ninja enforces explicit dependencies before order-only
On 04/04/2013 07:57 AM, Peter Kümmel wrote: On 02.04.2013 15:19, Brad King wrote: build libA.a: C_STATIC_LIBRARY_LINKER CMakeFiles/A.dir/a.c.o POST_BUILD = cd .../build cp .../a.c a.txt In build.ninja is no rule for coping a.c to a.txt at all. Seems support for add_custom_command(TARGET) is missing or broken. No, the CMakeLists.txt code I posted does not even tell CMake that any particular rule generates a.txt. The expectation is that by the time the rules for CMake target B are evaluated the file will have been created due to the order-dependency of B on A. All the other (Makefiles, VS, Xcode) produce build systems that evaluate file-level dependencies inside each main CMake target separately. Ninja has a monolithic file so it needs additional work to achieve this. The solution Robert proposed is to add rules like build a.txt : phony a.txt for all the file-level dependencies located in the build tree for which there is no custom command output. That may convince Ninja to skip complaining about the missing explicit dependency. -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
Re: [cmake-developers] Documentation 'latest' url
On Thu, Apr 4, 2013 at 2:33 PM, Brad King brad.k...@kitware.com wrote: On 04/04/2013 12:12 AM, Michael Wild wrote: On 09/21/2012 04:36 PM, Stephen Kelly wrote: This page has links for various versions of cmake: http://www.cmake.org/cmake/help/documentation.html Would it be possible to get a 'latest' url too, such as http://www.cmake.org/cmake/help/latest/cmake.html It would make more sense to link to such a url from the Qt documentation. Excavating this oldish, unanswered post: +1 from me! It certainly would help linking to the up-to-date docs from the Wiki... The problem with unversioned URLs is that people link to them based on their current content. When the content changes in the next version some of the links become nonsense. I don't know how many times I've seen links to a version control web viewer posted to say look at line 10 here, and of course line 10 has long since changed because they didn't use a URL that specifies the repository version. What we need is an unversioned URL that automatically redirects to the latest versioned URL. That way someone following a link that is intended to be unversioned will get a versioned URL in their browser. Unfortunately server-side redirects cause some browsers to strip the #tag part of the URLs, and client-side redirects require Javascript. -Brad Thanks for the details. Not worth the trouble, then. 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] ninja enforces explicit dependencies before order-only
My current work in progress on this problem can be found at: https://github.com/robertmaynard/CMake/tree/ninja_phony_file_targets On Thu, Apr 4, 2013 at 8:20 AM, Brad King brad.k...@kitware.com wrote: On 04/04/2013 07:57 AM, Peter Kümmel wrote: On 02.04.2013 15:19, Brad King wrote: build libA.a: C_STATIC_LIBRARY_LINKER CMakeFiles/A.dir/a.c.o POST_BUILD = cd .../build cp .../a.c a.txt In build.ninja is no rule for coping a.c to a.txt at all. Seems support for add_custom_command(TARGET) is missing or broken. No, the CMakeLists.txt code I posted does not even tell CMake that any particular rule generates a.txt. The expectation is that by the time the rules for CMake target B are evaluated the file will have been created due to the order-dependency of B on A. All the other (Makefiles, VS, Xcode) produce build systems that evaluate file-level dependencies inside each main CMake target separately. Ninja has a monolithic file so it needs additional work to achieve this. The solution Robert proposed is to add rules like build a.txt : phony a.txt for all the file-level dependencies located in the build tree for which there is no custom command output. That may convince Ninja to skip complaining about the missing explicit dependency. -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 -- Robert Maynard -- 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 0014061]: COVERAGE_EXTRA_FLAGS not respected when coverage is run from ctest script
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14061 == Reported By:Andreas Langs Assigned To: == Project:CMake Issue ID: 14061 Category: CTest Reproducibility:always Severity: major Priority: high Status: new == Date Submitted: 2013-04-04 16:54 CEST Last Modified: 2013-04-04 16:54 CEST == Summary:COVERAGE_EXTRA_FLAGS not respected when coverage is run from ctest script Description: I configure my project with pre-DCOVERAGE_EXTRA_FLAGS:STRING=-l -p/pre. Now if I run the coverage with prectest -D ExperimentalCoverage -VV/pre I can see that the arguments -l -p are passed to the gcov executable. If I invoke the coverage with the prectest_coverage()/pre command in a ctest script which I run with prectest -S script.cmake -VV/pre I see that the arguments are not passed to gcov, even the default argument -l is not passed. Additional Information: Running both described variants with the --debug option I see that when running without the script the function precmCTest::UpdateCTestConfiguration()/pre is called and all values from DartConfiguration.tcl are read. Running with the script the function precmCTest::UpdateCTestConfiguration()/pre is left early and the values from DartConfiguration.tcl are not read, in this case especially CoverageExtraFlags which holds the gcov arguments. The variable preCOVERAGE_EXTRA_FLAGS/pre was introduced with commit http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2f309cba455d0a946e935f66a53561ba64717faf To fix this bug I think and addition to precmCTestCoverageCommand::InitializeHandler()/pre needs to be made: prethis-CTest-SetCTestConfigurationFromCMakeVariable(this-Makefile, CoverageExtraFlags, CTEST_COVERAGE_EXTRA_FLAGS);/pre == Issue History Date ModifiedUsername FieldChange == 2013-04-04 16:54 Andreas Langs 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
Re: [cmake-developers] CMake master, Qt dialog and Qt4/5 installed has problems
On Thu, Apr 4, 2013 at 6:36 AM, Stephen Kelly steve...@gmail.com wrote: Stephen Kelly wrote: Marcus D. Hanwell wrote: Hi, I was updating my machine earlier today, and wanted to build the latest CMake master (00ef90). I am using Arch Linux with Qt 4 and Qt 5 installed. If I compile with qmake-qt4 then I see the following compile failure, Please also try the workaround-usr-move-qt5 branch on stage. My other question is - are we forcing Qt 5 when available over Qt 4 for the CMake Qt dialog? I will try to take a look at the branch in the next few days, until then the dashboard submission will continue to fail until this is fixed, http://open.cdash.org/viewBuildError.php?buildid=2864935 That is built with cmake master as of yesterday, and I can continue to block out the Qt 5 code until this is fixed when building CMake. 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] CMake master, Qt dialog and Qt4/5 installed has problems
Marcus D. Hanwell wrote: My other question is - are we forcing Qt 5 when available over Qt 4 for the CMake Qt dialog? If Qt 5 is available then it is preferred, yes. Until recently, that was the only way possible. Thanks, Steve. -- 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 0014062]: Setting Compiler and Linker PDB to the same path in Visual Studio is unsupported.
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14062 == Reported By:Robert McMillan Assigned To: == Project:CMake Issue ID: 14062 Category: CMake Reproducibility:always Severity: major Priority: high Status: new == Date Submitted: 2013-04-04 17:36 EDT Last Modified: 2013-04-04 17:36 EDT == Summary:Setting Compiler and Linker PDB to the same path in Visual Studio is unsupported. Description: I just got conformation from Calvin Clark, a Senior Consultant with Microsoft, that CMake's practice of setting the Compiler and Linker PDB to the same file is unsupported. It can caused corruption of the PDB during incremental linking, and it can cause very severe linker/build performance degradation for large projects. We have been experiencing a 4X increase in link times due to this issue, and when you multiply that by 100 projects in our app, times 100 developers on our project, it adds up to a very significant loss of productivity. We are considering making a local build of CMake to fix the issue, it is very serious. The feature in 2.8.10 to override the PDB location is not sufficient, because this will change the location for both the compiler and linker PDB. Also, users who are experiencing the issue have no idea why their build times are slow, and that the PDB location is the cause of the problem. The correct fix would really be to NOT SET THE COMPILER PDB LOCATION AT ALL! This will result in a vc100.pdb file being created automatically in the intermediate directory, as Microsoft intended. The compiler PDB is truly an intermediate file, and is not supposed to be a permanent artifact of the build, unlike the linker PDB. They are fundamentally different animals. I can put you in touch with Microsoft if you want direct confirmation of my findings. Steps to Reproduce: Generate any Visual Studio project using Cmake. The Compiler and Linker PDB location is the same, this is unsupported and causes problems. == Issue History Date ModifiedUsername FieldChange == 2013-04-04 17:36 Robert McMillanNew 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
