[cmake-developers] Qt builds: module machine type 'x64' conflicts with target machine type 'X86'
Hi, A new Qt CI machine machine is hitting problems with the CMake unit tests: http://thread.gmane.org/gmane.comp.lib.qt.devel/10746 Any idea what the problem could be there? 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] Suggestion: CMAKE_TOOLCHAIN_FILE warning improvement
Laszlo Papp wrote: Hi, Just found this post from Brad: http://www.cmake.org/pipermail/cmake/2011-February/042556.html I would suggest to improve the warning message. It is not exactly clear why that happens to a user like me. My colleague saw this warning in his cmake output when he was testing a toolchain file. After seeing it, he didn't even try the build, he just told me the toolchain file was broken. I told him about this warning being bogus, he ran the build, and of course it worked :). Is there any reason this variable shouldn't be special-cased in the unused variable handling? If the special case is spelled correctly, it should be fine. 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] Re: Qt builds: module machine type 'x64' conflicts with target machine type 'X86'
You’re building a 32-bit CMake and trying to link it to a 64-bit Qt. Why do you expect that should work? From: Stephen Kelly Sent: Wednesday, April 10, 2013 4:03 AM To: cmake-developers@cmake.org Hi, A new Qt CI machine machine is hitting problems with the CMake unit tests: http://thread.gmane.org/gmane.comp.lib.qt.devel/10746 Any idea what the problem could be there? 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-- 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 builds: module machine type 'x64' conflicts with target machine type 'X86'
On 04/10/2013 01:29 PM, David Cole wrote: You’re building a 32-bit CMake and trying to link it to a 64-bit Qt. Why do you expect that should work? I'm not trying build CMake and I'm not trying to link CMake to Qt. The Qt CI machines download CMake from http://www.cmake.org/cmake/resources/software.html (currently the Windows machines download CMake 2.8.9) and use that to run the Qt CMake unit tests. I didn't expect that CMake would have to be a 64 bit build in order to use a 64 bit Qt correctly. That is not the impression I get from http://www.cmake.org/pipermail/cmake/2008-October/024701.html for example. I don't know anything about building on Windows, so that might indeed be the problem. Can you confirm that it's not a misunderstanding? Thanks, Steve. *From:* Stephen Kelly *Sent:* Wednesday, April 10, 2013 4:03 AM *To:* cmake-developers@cmake.org Hi, A new Qt CI machine machine is hitting problems with the CMake unit tests: http://thread.gmane.org/gmane.comp.lib.qt.devel/10746 Any idea what the problem could be there? 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 -- 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 builds: module machine type 'x64' conflicts with target machine type 'X86'
Eric Noulard wrote: I don't know anything about building on Windows, so that might indeed be the problem. Can you confirm that it's not a misunderstanding? In http://thread.gmane.org/gmane.comp.lib.qt.devel/10746 we can read: 3-- Build started: Project: axserverapp, Configuration: Release Win32 -- (or in other places: Microsoft (R) Visual Studio Version 10.0.40219.1. Copyright (C) Microsoft Corp. All rights reserved. 1-- Clean started: Project: ALL_BUILD, Configuration: Release Win32 -- 1Build started 4/5/2013 2:45:03 PM. ) which means that the build target Win32 i.e. a 32 bits build. Ah, see? I didn't even know what to look for :). Could you check that the concerned build targets Win64 and not win32 ? I don't have direct access to the machines, so I can't really check anything except the cmake command lines, which are generated by the expect_pass macro and similar here: https://qt.gitorious.org/qt/qtbase/blobs/HEAD/src/corelib/Qt5CTestMacros.cmake which is used here for example: https://qt.gitorious.org/qt/qtbase/blobs/HEAD/tests/auto/cmake/CMakeLists.txt which is used by a cmake command generated here: https://qt.gitorious.org/qt/qtbase/blobs/HEAD/mkspecs/features/ctest_testcase.prf So, how is the target 32bit/64bit determined? An option to cmake at cmake time? 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] Qt builds: module machine type 'x64' conflicts with target machine type 'X86'
Stephen Kelly wrote: So, how is the target 32bit/64bit determined? An option to cmake at cmake time? It seems to be determined by the generator: http://stackoverflow.com/questions/3785976/cmake-generate-visual-studio-2008-solution-for-win32-and-x64 I'll figure out a way to determine that in the ctest_testcase.prf file and set the 64 bit version. 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] Qt builds: module machine type 'x64' conflicts with target machine type 'X86'
2013/4/10 Stephen Kelly steve...@gmail.com Stephen Kelly wrote: So, how is the target 32bit/64bit determined? An option to cmake at cmake time? It seems to be determined by the generator: http://stackoverflow.com/questions/3785976/cmake-generate-visual-studio-2008-solution-for-win32-and-x64 I was about to say so. Try git grep Win64 in the CMake source tree. You'll see that as well. I'll figure out a way to determine that in the ctest_testcase.prf file and set the 64 bit version. check were CMAKE_GENERATOR variable is setup. It is then used at line 73 of https://qt.gitorious.org/qt/qtbase/blobs/HEAD/mkspecs/features/ctest_testcase.prf cmake $$_PRO_FILE_PWD_ $$CMAKE_GENERATOR \ $$CMAKE_MODULE_DEFINES \ ... 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 -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- 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 builds: module machine type 'x64' conflicts with target machine type 'X86'
- Original Message - Eric Noulard wrote: I don't know anything about building on Windows, so that might indeed be the problem. Can you confirm that it's not a misunderstanding? In http://thread.gmane.org/gmane.comp.lib.qt.devel/10746 we can read: 3-- Build started: Project: axserverapp, Configuration: Release Win32 -- (or in other places: Microsoft (R) Visual Studio Version 10.0.40219.1. Copyright (C) Microsoft Corp. All rights reserved. 1-- Clean started: Project: ALL_BUILD, Configuration: Release Win32 -- 1Build started 4/5/2013 2:45:03 PM. ) which means that the build target Win32 i.e. a 32 bits build. Ah, see? I didn't even know what to look for :). Could you check that the concerned build targets Win64 and not win32 ? I don't have direct access to the machines, so I can't really check anything except the cmake command lines, which are generated by the expect_pass macro and similar here: https://qt.gitorious.org/qt/qtbase/blobs/HEAD/src/corelib/Qt5CTestMacros.cmake which is used here for example: https://qt.gitorious.org/qt/qtbase/blobs/HEAD/tests/auto/cmake/CMakeLists.txt which is used by a cmake command generated here: https://qt.gitorious.org/qt/qtbase/blobs/HEAD/mkspecs/features/ctest_testcase.prf So, how is the target 32bit/64bit determined? An option to cmake at cmake time? If the generator is a makefile, it is already determined by the environment. If the generator is Visual Studio, its determined by the chosen generator. From looking here: https://qt.gitorious.org/qt/qtbase/blobs/HEAD/mkspecs/features/ctest_testcase.prf It appears it needs more logic to handle the CMAKE_GENERATOR variable. If a visual studio generator is going to be used, then it'll probably need logic to determine which version of visual studio it is to choose the correct visual studio generator (because of project file format changes). For example, the correct generator could be any of Visual Studio 10 Visual Studio 10 Win64 Visual Studio 11 etc... http://www.cmake.org/cmake/help/v2.8.10/cmake.html#section_Generators If NMake Makefiles are still used to build Qt with MSVC, then perhaps you can simply set the generator to NMake Makefiles. 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Qt builds: module machine type 'x64' conflicts with target machine type 'X86'
clin...@elemtech.com wrote: It appears it needs more logic to handle the CMAKE_GENERATOR variable. If a visual studio generator is going to be used, then it'll probably need logic to determine which version of visual studio it is to choose the correct visual studio generator (because of project file format changes). For example, the correct generator could be any of Visual Studio 10 Visual Studio 10 Win64 Visual Studio 11 etc... http://www.cmake.org/cmake/help/v2.8.10/cmake.html#section_Generators If NMake Makefiles are still used to build Qt with MSVC, then perhaps you can simply set the generator to NMake Makefiles. I've written this patch: https://codereview.qt-project.org/#change,53410 which I think will solve the problem. 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] Suggestion: CMAKE_TOOLCHAIN_FILE warning improvement
On 04/10/2013 07:20 AM, Stephen Kelly wrote: Is there any reason this variable shouldn't be special-cased in the unused variable handling? If the special case is spelled correctly, it should be fine. If you want to add a whitelist to suppress the warning that's fine with me. -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] Suggestion: CMAKE_TOOLCHAIN_FILE warning improvement
Am 10.04.2013 16:17, schrieb Brad King: On 04/10/2013 07:20 AM, Stephen Kelly wrote: Is there any reason this variable shouldn't be special-cased in the unused variable handling? If the special case is spelled correctly, it should be fine. If you want to add a whitelist to suppress the warning that's fine with me. I think what Stephen had in mind (I really hope he had *g*) is to show a different warning in that case, telling the user that the toolchain file is ignored on any subsequent run. Eike -- 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] Suggestion: CMAKE_TOOLCHAIN_FILE warning improvement
On 04/10/2013 10:30 AM, Rolf Eike Beer wrote: I think what Stephen had in mind (I really hope he had *g*) is to show a different warning in that case, telling the user that the toolchain file is ignored on any subsequent run. Another approach is to not warn when the -DFOO=bar option just repeats a value that is already in the cache without changing it. That would be a more general solution that covers this case too. -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] [CMake 0014070]: CMake with Visual Studio 2012 broken
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14070 == Reported By:Jarle Aase Assigned To: == Project:CMake Issue ID: 14070 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2013-04-10 10:53 EDT Last Modified: 2013-04-10 10:53 EDT == Summary:CMake with Visual Studio 2012 broken Description: After re-install of Visual Studio 2012 with all updates, CMake can no longer configure projects for this compiler. It appears like CMake tries to use some manifest:embed option, which is no longer supported. Steps to Reproduce: Just configure a project for Visual Studio 11. I used the CMakeLists.txt file below: cmake_minimum_required (VERSION 2.8) add_executable(test test.cpp) Additional Information: Output from CMake: The C compiler identification is MSVC 17.0.51106.1 The CXX compiler identification is MSVC 17.0.51106.1 Check for working C compiler using: Visual Studio 11 Check for working C compiler using: Visual Studio 11 -- broken CMake Error at C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:61 (message): The C compiler C:/Program Files (x86)/Microsoft Visual Studio 11.0/VC/bin/cl.exe is not able to compile a simple test program. It fails with the following output: Change Dir: C:/tmp/testCmake/build/CMakeFiles/CMakeTmp Run Build Command:C:\PROGRA~2\MICROS~2.0\Common7\IDE\devenv.com CMAKE_TRY_COMPILE.sln /build Debug /project cmTryCompileExec3319963856 Microsoft (R) Microsoft Visual Studio 2012 Version 11.0.51106.1. Copyright (C) Microsoft Corp. All rights reserved. 1-- Build started: Project: cmTryCompileExec3319963856, Configuration: Debug Win32 -- 1 Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.30729.01 for 80x86 1 Copyright (C) Microsoft Corporation. All rights reserved. 1 1 cl /c /Zi /W3 /WX- /Od /Ob0 /Oy- /D WIN32 /D _WINDOWS /D _DEBUG /D CMAKE_INTDIR=\Debug\ /D _MBCS /Gm- /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /FocmTryCompileExec3319963856.dir\Debug\\ /FdcmTryCompileExec3319963856.dir\Debug\vc110.pdb /Gd /TC /analyze- /errorReport:prompt testCCompiler.c 1 1 testCCompiler.c 1LINK : fatal error LNK1117: syntax error in option 'manifest:embed' == Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped == CMake will not be able to correctly generate this project. Call Stack (most recent call first): Configuring incomplete, errors occurred! == Issue History Date ModifiedUsername FieldChange == 2013-04-10 10:53 Jarle Aase 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
[cmake-developers] CMake crashes on removing INCLUDE_DIRECTORIES property
Steve, Since this commit: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=18a3195a CMake crashes on the code set_property(DIRECTORY PROPERTY INCLUDE_DIRECTORIES) because code like this-IncludeDirectoriesEntries.push_back( cmValueWithOrigin(value, lfbt)); assumes that value is non-null. However, the internal value used when *removing* a property is exactly null (0). It is not just a matter of tolerating a null value. The value indicates that the property should be removed altogether. Please fix the include directory vector representation to support removing the property altogether and add a test case. We'll need to get this in before 2.8.11 final. Thanks, -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] Qt builds: module machine type 'x64' conflicts with target machine type 'X86'
On 4/10/2013 11:54 AM, Stephen Kelly wrote: (at the very bottom) http://testresults.qt-project.org/ci/QtBase_stable_Integration/build_00894/win64-msvc2012_developer-build_qtnamespace_Windows_8/log.txt.gz Any ideas? I think you want this generator: Visual Studio 11 Win64 -- Check for working C compiler using: Visual Studio 10 Win64 -- broken CMake Error at C:/CMake/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:52 (MESSAGE): The C compiler C:/Program Files (x86)/Microsoft Visual Studio 11.0/VC/bin/amd64/cl.exe is not able to compile a simple test program. It fails with the following output: Change Dir: C:/work/build/qt/qtbase/tests/auto/cmake/build/CMakeFiles/CMakeTmp Run Build Command:C:\PROGRA~2\MICROS~1.0\Common7\IDE\devenv.com CMAKE_TRY_COMPILE.sln /build Debug /project cmTryCompileExec3680607716 Microsoft (R) Microsoft Visual Studio 2012 Version 11.0.51106.1. Copyright (C) Microsoft Corp. All rights reserved. I think that Microsoft (R) Microsoft Visual Studio 2012 Version 11.0.51106.1. is not VS 10, but rather 11. -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 -- 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 builds: module machine type 'x64' conflicts with target machine type 'X86'
Bill Hoffman wrote: On 4/10/2013 11:54 AM, Stephen Kelly wrote: (at the very bottom) http://testresults.qt-project.org/ci/QtBase_stable_Integration/build_00894/win64-msvc2012_developer-build_qtnamespace_Windows_8/log.txt.gz Any ideas? I think you want this generator: Visual Studio 11 Win64 Yes, I think you're right. I've updated the patch with that information now. 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] Qt builds: module machine type 'x64' conflicts with target machine type 'X86'
On 4/10/2013 12:22 PM, Stephen Kelly wrote: Yes, I think you're right. I've updated the patch with that information now. Seems a bit unstable to hard code the version. I wonder if you can detect the one that is being used somehow? -Bill -- 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] Suggestion: CMAKE_TOOLCHAIN_FILE warning improvement
Brad King wrote: On 04/10/2013 10:30 AM, Rolf Eike Beer wrote: I think what Stephen had in mind (I really hope he had *g*) is to show a different warning in that case, telling the user that the toolchain file is ignored on any subsequent run. Another approach is to not warn when the -DFOO=bar option just repeats a value that is already in the cache without changing it. That would be a more general solution that covers this case too. But the toolchain file is indeed a bit special, at it is only evaluated once. Telling a user _why_ it is wrong to pass it again, especially if it is different, would be a good idea IMHO. Which doesn't conflict with your solution. Eike -- signature.asc Description: This is a digitally signed message part. -- 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] Determining version and arch for Visual Studio generators.
Bill Hoffman wrote: Seems a bit unstable to hard code the version. I wonder if you can detect the one that is being used somehow? I don't think it's unstable, but I do think the version and arch should be detected somehow. Would it be possible for cmake to run devenv to check the version and arch before setting the default generator? That would have anticipated and pre- solved the bug here. 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] Determining version and arch for Visual Studio generators.
Stephen Kelly wrote: Bill Hoffman wrote: Seems a bit unstable to hard code the version. I wonder if you can detect the one that is being used somehow? I don't think it's unstable, but I do think the version and arch should be detected somehow. Would it be possible for cmake to run devenv to check the version and arch before setting the default generator? That would have anticipated and pre- solved the bug here. I suppose the arch problem occurred because Qt was built in 64bit mode, and that has nothing to do with devenv. I can put a variable in the Qt5Core config file containing the arch. Better yet, I can put it in a INTERFACE_TARGET_ARCH target property and have cmake ensure that all targets are compatible. Such a TARGET_ARCH should be a built-in property in CMake, and CMake should also check it for each target against the generator. That would at least give a sensible error message about what the problem is at cmake-time. This might also be generally useful for storing an arch triple on linux systems? Can 32 and 64 bit libs be mixed there? This isn't for 2.8.11 obviously. 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] Determining version and arch for Visual Studio generators.
On 4/10/2013 4:45 PM, Stephen Kelly wrote:
I don't think it's unstable, but I do think the version and arch should be
detected somehow.
I take it back.
It is not hard coded. It is just matching qt win32-msvc2010,
win32-msvc2012 with the correct CMake generator:
win32-g++*:CMAKE_GENERATOR = -G \MinGW Makefiles\
41 win32:equals(QT_ARCH, x86_64) {
42 win32-msvc2010:CMAKE_GENERATOR = -G \Visual Studio
10 Win64\
43 win32-msvc2012:CMAKE_GENERATOR = -G \Visual Studio
11 Win64\
44 }
41 45
What about VS 9, seems to be missing?
What are all the possible values of win32-??
Would it be possible for cmake to run devenv to check the version and arch
before setting the default generator? That would have anticipated and pre-
solved the bug here.
I suppose the arch problem occurred because Qt was built in 64bit mode, and
that has nothing to do with devenv.
Yes, that is correct, you have to figure out if Qt is 64 first, and then
configure CMake.
I can put a variable in the Qt5Core config file containing the arch. Better
yet, I can put it in a INTERFACE_TARGET_ARCH target property and have cmake
ensure that all targets are compatible.
Such a TARGET_ARCH should be a built-in property in CMake, and CMake should
also check it for each target against the generator. That would at least
give a sensible error message about what the problem is at cmake-time.
This might also be generally useful for storing an arch triple on linux
systems? Can 32 and 64 bit libs be mixed there?
I don't think they can be mixed anywhere.
This isn't for 2.8.11 obviously.
Sure.
-Bill
--
Bill Hoffman
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065
bill.hoff...@kitware.com
http://www.kitware.com
518 881-4905 (Direct)
518 371-3971 x105
Fax (518) 371-4573
--
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] Determining version and arch for Visual Studio generators.
Bill Hoffman wrote:
What about VS 9, seems to be missing?
The Qt CI system only tests 2010 and 2012:
http://testresults.qt-project.org/ci/QtBase_dev_Integration/latest-success/
The wince70embedded-armv4i-msvc2008_Windows_7 build is currently failing for
other reasons, but it's a 'non-enforcing' configuration, meaning the tests
don't have to pass there anyway. If that changes, I'll notice if the cmake
tests fail.
Apart from that, if you want to test the Qt5 cmake files on other
configurations (and with multiple generators) and extending the
ctest_testcase.prf would be useful, we can do that. I think for non-64-bit
builds, cmake already picks the right default though.
What are all the possible values of win32-??
qtbase-stable/mkspecs{(no branch)}$ find -name win32-msvc*
./win32-msvc2012
./win32-msvc2005
./win32-msvc2008
./win32-msvc2010
./unsupported/win32-msvc2003
More generally, the directories here mostly correspond to the possible
values which can be used there (excluding the dirs like 'common', 'device'
'unsupported' 'features' etc):
https://qt.gitorious.org/qt/qtbase/trees/HEAD/mkspecs
This might also be generally useful for storing an arch triple on linux
systems? Can 32 and 64 bit libs be mixed there?
I don't think they can be mixed anywhere.
Great, that means this would be a simple string comparison with no need to
parse and extract the info from triples.
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 0014073]: VS2010 / VS2012 - Improper escape of semicolon in compile definition
The following issue has been SUBMITTED. == http://cmake.org/Bug/view.php?id=14073 == Reported By:Jean-Christophe Fillion-Robin Assigned To: == Project:CMake Issue ID: 14073 Category: CMake Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2013-04-11 00:30 WAT Last Modified: 2013-04-11 00:30 WAT == Summary:VS2010 / VS2012 - Improper escape of semicolon in compile definition Description: To reproduce the problem, create a simple project abd set the COMPILE_DEFINITIONS similarly to what is done here: https://github.com/davidsansome/python-cmake-buildsystem/blob/master/cmake/libpython/CMakeLists.txt#L161-173 == Issue History Date ModifiedUsername FieldChange == 2013-04-11 00:30 Jean-Christophe Fillion-RobinNew 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
[cmake-developers] Building with Qt for the Raspberry Pi with CMake
Hi,
This is mostly just feedback on some experience with cross-compiling.
As part of trying to figure out to what extent Qt 5 needs to be patched to
solve the kind of issue raised in
http://public.kitware.com/Bug/view.php?id=14041
and fixed in 6c613b433c45efb0bb013a6bd668cbb8ac740259, I've been toying with
building Qt 5 for the Raspberry Pi (raspbian image).
I configured Qt like this:
/home/stephen/dev/src/qtbase-stable/configure -prefix
/home/stephen/dev/prefix/rpi -release -device linux-rasp-pi-g++ -make libs -
device-option CROSS_COMPILE=/home/stephen/rpi/gcc-4.7-linaro-rpi-
gnueabihf/bin/arm-linux-gnueabihf- -sysroot /home/stephen/rpi/rasp-pi-
rootfs/ -opensource -confirm-license -no-pch
[From the prefix you'll notice I'm not trying to reproduce #14041 here yet]
I can use the resulting Qt 5 build by passing a prefix and toolchain:
cmake .. -DCMAKE_PREFIX_PATH=/home/stephen/rpi/rasp-pi-
rootfs/home/stephen/dev/prefix/rpi/ -
DCMAKE_TOOLCHAIN_FILE=../rpiToolchain.cmake
$ cat ../rpiToolchain.cmake
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_C_COMPILER /home/stephen/rpi/gcc-4.7-linaro-rpi-
gnueabihf/bin/arm-linux-gnueabihf-gcc)
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
[Side note, a colleague is working on a patch to generate such a toolchain
file as part of the Qt build. The Qt mkspecs have all needed information.
Any comments on that?]
I can then build GammaRay for the Pi if I patch it like this:
diff --git a/CMakeLists.txt b/CMakeLists.txt
index ca7a377..ea0b8d6 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -91,6 +91,32 @@ if(Qt5Core_FOUND)
include(cmake/ECMQt4To5Porting.cmake)
include_directories(${QT_INCLUDES}) # TODO: Port away from this.
+
+ find_library(QTGUI_EGL_LIB EGL
+PATHS /home/stephen/rpi/rasp-pi-rootfs/opt/vc/lib NO_DEFAULT_PATH)
+ if (QTGUI_EGL_LIB)
+set_property(TARGET Qt5::Gui APPEND PROPERTY
+ IMPORTED_LINK_DEPENDENT_LIBRARIES_DEBUG ${QTGUI_EGL_LIB})
+set_property(TARGET Qt5::Gui APPEND PROPERTY
+IMPORTED_LINK_DEPENDENT_LIBRARIES_RELEASE ${QTGUI_EGL_LIB})
+ endif()
+
+ set(CMAKE_EXTRA_SHARED_LIBRARY_SUFFIXES .so.1)
+ find_library(QTCORE_Z_LIB_1 libz.so.1 PATHS
+/home/stephen/rpi/rasp-pi-rootfs/lib/arm-linux-gnueabihf/
+NO_DEFAULT_PATH)
+ find_library(QTCORE_Z_LIB z PATHS
+/home/stephen/rpi/rasp-pi-rootfs/usr/lib/arm-linux-gnueabihf/
+NO_DEFAULT_PATH)
+ if (QTCORE_Z_LIB_1 AND QTCORE_Z_LIB)
+set_property(TARGET Qt5::Core APPEND PROPERTY
+ IMPORTED_LINK_DEPENDENT_LIBRARIES_DEBUG
+${QTCORE_Z_LIB} ${QTCORE_Z_LIB_1})
+set_property(TARGET Qt5::Core APPEND PROPERTY
+ IMPORTED_LINK_DEPENDENT_LIBRARIES_RELEASE
+${QTCORE_Z_LIB} ${QTCORE_Z_LIB_1})
+ endif()
This is working toward a patch to generate the
IMPORTED_LINK_DEPENDENT_LIBRARIES_* in Qt itself.
In regular builds of Qt 5, the IMPORTED_LINK_DEPENDENT_LIBRARIES_* does not
need to be specified because libz and libEGL are usually in standard
locations, so they don't need to be in -rpath-link specified directories.
However, the Raspberry Pi has libz.so in some funny locations:
stephen@hal:~/rpi/rasp-pi-rootfs$ find -name *libz*
./lib/arm-linux-gnueabihf/libz.so.1
./lib/arm-linux-gnueabihf/libz.so.1.2.7
./usr/lib/arm-linux-gnueabihf/libz.so
./usr/lib/arm-linux-gnueabihf/libz.a
stephen@hal:~/rpi/rasp-pi-rootfs$ ll usr/lib/arm-linux-gnueabihf/libz.*
-rw-r--r-- 1 stephen stephen 104598 Jun 24 2012 usr/lib/arm-linux-
gnueabihf/libz.a
lrwxrwxrwx 1 stephen stephen 46 Apr 9 17:03 usr/lib/arm-linux-
gnueabihf/libz.so - ../../../lib/arm-linux-gnueabihf/libz.so.1.2.7
stephen@hal:~/rpi/rasp-pi-rootfs$ ll lib/arm-linux-gnueabihf/libz.*
lrwxrwxrwx 1 stephen stephen13 Jun 24 2012 lib/arm-linux-
gnueabihf/libz.so.1 - libz.so.1.2.7
-rw-r--r-- 1 stephen stephen 87792 Jun 24 2012 lib/arm-linux-
gnueabihf/libz.so.1.2.7
So, the libz.so.1 and libz.so are in different directories.
stephen@hal:~/rpi/rasp-pi-rootfs/home/stephen/dev/prefix/rpi/lib$
~/rpi/gcc-4.7-linaro-rpi-gnueabihf/bin/arm-linux-gnueabihf-ldd --root
~/rpi/rasp-pi-rootfs/ libQt5Core.so.5.1.0
libpthread.so.0 = /lib/arm-linux-gnueabihf/libpthread.so.0
(0xdeadbeef)
libc.so.6 = /lib/arm-linux-gnueabihf/libc.so.6 (0xdeadbeef)
ld-linux-armhf.so.3 = /lib/ld-linux-armhf.so.3 (0xdeadbeef)
libz.so.1 = /lib/arm-linux-gnueabihf/libz.so.1 (0xdeadbeef)
libgcc_s.so.1 = /lib/arm-linux-gnueabihf/libgcc_s.so.1
(0xdeadbeef)
libdl.so.2 = /lib/arm-linux-gnueabihf/libdl.so.2 (0xdeadbeef)
librt.so.1 = /lib/arm-linux-gnueabihf/librt.so.1 (0xdeadbeef)
libstdc++.so.6 = /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
(0xdeadbeef)
libm.so.6 = /lib/arm-linux-gnueabihf/libm.so.6 (0xdeadbeef)
The libQt5Core.so links to the libz.so.1 version. So, for some reason I seem
to need both
Re: [CMake] INSTALL_INTERFACE question
clin...@elemtech.com wrote:
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
$BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR};
${CMAKE_CURRENT_SOURCE_DIR}
$INSTALL_INTERFACE:${CMAKE_INSTALL_PREFIX}/include
)
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 $INSTALL_INTERFACE:include , it complains about it being a
relative path.
Indeed. The $INSTALL_PREFIX generator expression was created to address
this issue. It expands to the ${_IMPORT_PREFIX}. Where did you see the
example above? In an old commit message? It doesn't seem to be in the code:
$ git grep INSTALL_PREFIX./include
Tests/ExportImport/Export/CMakeLists.txt:$INSTALL_INTERFACE:
$INSTALL_PREFIX/include/${_libName}
Tests/ExportImport/Export/CMakeLists.txt: INTERFACE_INCLUDE_DIRECTORIES
$INSTALL_INTERFACE:$INSTALL_PREFIX/include/testSharedLibRequired
Tests/ExportImport/Export/CMakeLists.txt: INTERFACE_INCLUDE_DIRECTORIES
$INSTALL_INTERFACE:$INSTALL_PREFIX/include/testSharedLibDepends
Tests/RunCMake/GeneratorExpression/BadInstallPrefix.cmake:
$INSTALL_PREFIX/include
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] INSTALL_INTERFACE question
Stephen Kelly wrote: Where did you see the example above? In an old commit message? It doesn't seem to be in the code: Ah, I found and fixed it on the wiki page: http://community.kde.org/Frameworks/Epics/CMake_target_usage_requirements 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] INSTALL_INTERFACE question
Yeah, that's it. Thanks. That page was referenced by a recent kitware blog. http://www.kitware.com/blog/home/post/462 Clint - Reply message - From: Stephen Kelly steve...@gmail.com Date: Wed, Apr 10, 2013 1:08 am Subject: [CMake] INSTALL_INTERFACE question To: cmake@cmake.org Stephen Kelly wrote: Where did you see the example above? In an old commit message? It doesn't seem to be in the code: Ah, I found and fixed it on the wiki page: http://community.kde.org/Frameworks/Epics/CMake_target_usage_requirements 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://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] Disable creation of uninstall link in windows start menu (CMAKE + CPACK + NSIS)
Hi, I like to disable the creation of the uninstall link in the windows start menu when using the NSIS generator in combination with CMAKE and CPACK. When executing the generated NSIS installer using the standard configuration of CPACK the uninstall link is automatically added to the windows start menu. Until now I did not find any option in CMAKE/CPACK to prevent this. I am using CMAKE 2.8.10.2 on Windows 7 64 bit (SP1, fully patched). I hope anyone can help me with this problem. Thanks in advance, Hagen -- 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] CTest / CDash integration
Sorry, but I have to keep complaining about the documentation. Please
excuse the ranting.
Just one example from the manual:
ctest --build-options: Add extra options to the build step.
This option must be the last option with the exception of
--test-command
End of available information.
I have not been able to figure out which CTEST_* variable these options
end up in, or how I could make them actually *affect* the build.
I am also still looking for a reference of variables used by CTest.
Quite obviously it is required to set both CTEST_SOURCE_DIRECTORY and
CTEST_BINARY_DIRECTORY in your script, as CTest keeps telling you if
you
try to execute an empty script. I wonder if it wouldn't be easier if
CTest
would assume the current directory as BINARY_DIR and the script
directory
as SOURCE_DIR by default, but that might be just me.
That I have to set CTEST_COMMAND manually when I obviously just called
the
executable, conveniently passing a working invocation in argv[0]).
Strange.
CTEST_SITE / CTEST_BUILD_NAME constitute the identification sent to the
CDash server, as I found out perusing some example scripts on the Wiki,
none of which really explaining what is done. Nice, but why ain't I
told
in plain English?
As SVN user, I have to set CTEST_CHECKOUT_COMMAND myself (to something
resembling svn checkout ${MY_REPOSITORY} ${CTEST_SOURCE_DIRECTORY}.
Figured it out, works. But apparently CTEST_UPDATE_COMMAND is something
else entirely, as CTest insists on appending update --non-interactive
on its own accord...
It is possible to trial error your way around all this, but I would
REALLY prefer to have a reference list, telling me which features I
might
be missing, or how I should escape quotation marks and semicolons in a
-DCMAKE_PREFIX_PATH= statement. Or why a statement that works when
given
as CTEST_CONFIGURE_COMMAND fails when passed in ctest_configure(
OPTIONS ).
Hence, again my question: Is the man page and the half-dozen pages in
the
Wiki really all there is in freely available documentation on CTest?
Regards,
--
Martin Baute
so...@rootdirectory.de
--
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] Ralph Barth/AEH/DBS/GDB ist außer Haus. Original subject: 'CMake Digest, Vol 108, Issue 29'
Ralph Barth will be out of the office starting 10.04.2013 and will be returning on 11.04.2013. Ich werde Ihre Nachrichten nach meiner Rückkehr beantworten. WLLM related questions pls. contact Sebastian Neusüß and Jens Keil. Theo Price Feed from EDRE pls contact Jens Keil - Deutsche Börse AG Chairman of the Supervisory Board/ Vorsitzender des Aufsichtsrats: Dr. Joachim Faber Executive Board/Vorstand: Dr. Reto Francioni (Chief Executive Officer/Vorsitzender), Andreas Preuss (Deputy Chief Executive Officer/ stellv. Vorsitzender), Gregor Pottmeyer, Hauke Stars, Jeffrey Tessler. Aktiengesellschaft with registered seat in/mit Sitz in Frankfurt am Main. Commercial register/Handelsregister: HRB 32232 Local court/Amtsgericht Frankfurt am Main. - Diese E-Mail enthaelt vertrauliche oder rechtlich geschuetzte Informationen. Wenn Sie nicht der beabsichtigte Empfaenger sind, informieren Sie bitte sofort den Absender und loeschen Sie diese E-Mail. Das unbefugte Kopieren dieser E-Mail oder die unbefugte Weitergabe der enthaltenen Informationen ist nicht gestattet. The information contained in this message is confidential or protected by law. If you are not the intended recipient, please contact the sender and delete this message. Any unauthorised copying of this message or unauthorised distribution of the information contained herein is prohibited. Legally required information for business correspondence/ Gesetzliche Pflichtangaben fuer Geschaeftskorrespondenz: http://deutsche-boerse.com/letterhead -- 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] CTest / CDash integration
Probably someone else can give you a better answer, but I ended up doing the
following:
ctest \
--build-and-test $SOURCE_DIR $BUILD_DIR \
--build-generator Unix Makefiles --build-makeprogram make \
-j $PARALLEL_JOBS \
--build-options -DCMAKE_CXX_COMPILER=$CXX -DCMAKE_C_COMPILER=$CC \
--test-command ctest -D Nightly
I.e. the CTEST_SOURCE_DIRECTORY and CTEST_BINARY_DIRECTORY variables are set
by the --build-and-test sourcedir builddir argument, and the build options
are only needed to pass extra variables to your build system.
HTH,
Johannes
On Wednesday, 10. April 2013, 16:09:10, Martin Baute wrote:
Sorry, but I have to keep complaining about the documentation. Please
excuse the ranting.
Just one example from the manual:
ctest --build-options: Add extra options to the build step.
This option must be the last option with the exception of
--test-command
End of available information.
I have not been able to figure out which CTEST_* variable these options
end up in, or how I could make them actually *affect* the build.
I am also still looking for a reference of variables used by CTest.
Quite obviously it is required to set both CTEST_SOURCE_DIRECTORY and
CTEST_BINARY_DIRECTORY in your script, as CTest keeps telling you if
you
try to execute an empty script. I wonder if it wouldn't be easier if
CTest
would assume the current directory as BINARY_DIR and the script
directory
as SOURCE_DIR by default, but that might be just me.
That I have to set CTEST_COMMAND manually when I obviously just called
the
executable, conveniently passing a working invocation in argv[0]).
Strange.
CTEST_SITE / CTEST_BUILD_NAME constitute the identification sent to the
CDash server, as I found out perusing some example scripts on the Wiki,
none of which really explaining what is done. Nice, but why ain't I
told
in plain English?
As SVN user, I have to set CTEST_CHECKOUT_COMMAND myself (to something
resembling svn checkout ${MY_REPOSITORY} ${CTEST_SOURCE_DIRECTORY}.
Figured it out, works. But apparently CTEST_UPDATE_COMMAND is something
else entirely, as CTest insists on appending update --non-interactive
on its own accord...
It is possible to trial error your way around all this, but I would
REALLY prefer to have a reference list, telling me which features I
might
be missing, or how I should escape quotation marks and semicolons in a
-DCMAKE_PREFIX_PATH= statement. Or why a statement that works when
given
as CTEST_CONFIGURE_COMMAND fails when passed in ctest_configure(
OPTIONS ).
Hence, again my question: Is the man page and the half-dozen pages in
the
Wiki really all there is in freely available documentation on CTest?
Regards,
--
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] CTest / CDash integration
ctest has long been quite under-documented
There are some open issues in the bug tracker:
http://public.kitware.com/Bug/view.php?id=10392
http://public.kitware.com/Bug/view.php?id=13836
What's needed is someone to go in and do the work to document it well.
Until that happens, your best bet is to ask specific questions here to fill in
the gaps...
HTH,
David C
On Apr 10, 2013, at 10:09 AM, Martin Baute so...@rootdirectory.de wrote:
Sorry, but I have to keep complaining about the documentation. Please
excuse the ranting.
Just one example from the manual:
ctest --build-options: Add extra options to the build step.
This option must be the last option with the exception of --test-command
End of available information.
I have not been able to figure out which CTEST_* variable these options
end up in, or how I could make them actually *affect* the build.
I am also still looking for a reference of variables used by CTest.
Quite obviously it is required to set both CTEST_SOURCE_DIRECTORY and
CTEST_BINARY_DIRECTORY in your script, as CTest keeps telling you if you
try to execute an empty script. I wonder if it wouldn't be easier if CTest
would assume the current directory as BINARY_DIR and the script directory
as SOURCE_DIR by default, but that might be just me.
That I have to set CTEST_COMMAND manually when I obviously just called the
executable, conveniently passing a working invocation in argv[0]). Strange.
CTEST_SITE / CTEST_BUILD_NAME constitute the identification sent to the
CDash server, as I found out perusing some example scripts on the Wiki,
none of which really explaining what is done. Nice, but why ain't I told
in plain English?
As SVN user, I have to set CTEST_CHECKOUT_COMMAND myself (to something
resembling svn checkout ${MY_REPOSITORY} ${CTEST_SOURCE_DIRECTORY}.
Figured it out, works. But apparently CTEST_UPDATE_COMMAND is something
else entirely, as CTest insists on appending update --non-interactive
on its own accord...
It is possible to trial error your way around all this, but I would
REALLY prefer to have a reference list, telling me which features I might
be missing, or how I should escape quotation marks and semicolons in a
-DCMAKE_PREFIX_PATH= statement. Or why a statement that works when given
as CTEST_CONFIGURE_COMMAND fails when passed in ctest_configure( OPTIONS ).
Hence, again my question: Is the man page and the half-dozen pages in the
Wiki really all there is in freely available documentation on CTest?
Regards,
--
Martin Baute
so...@rootdirectory.de
--
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] COMPONENTS for export files
On Wednesday 10 April 2013, Nico Schlömer wrote: Sounds pretty good! One question remains: Suppose I have components A, B, C, where both A and B depend on C. The link line that I'd pull in with FIND_PACKAGE(Mypackage COMPONENTS A B) Would be A libs, C libs, B libs, C libs where all of those could be sets. Is there a way to avoid including C's libs twice? (Is that desirable at all?) Is your question whether it is a problem that in the link command C libs will appear twice ? That's fine, no problem at all (for static libs even needed). 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://www.cmake.org/mailman/listinfo/cmake
[CMake] nested replacement with @@
Hi all,
in a ProjectContfigTemplate.cmake.in file, I'd like to have variables
such as ${${PROJECT_NAME}_VERSION}. In ${}-syntax, the nesting is
recognized properly, and this string would be replaced by, e.g.,
2.1.
I know need to have ${}-variables in the output file, so I tried to
switch to the @-syntax. Replacing the above line by
@@PROJECT_NAME@_VERSION@
doesn't work however: The output file contains
@Myproject_VERSION@
i.e., only the inner variable was replaced.
How to fix this?
Cheers,
Nico
--
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] nested replacement with @@
2013/4/10 Nico Schlömer nico.schloe...@gmail.com
Hi all,
in a ProjectContfigTemplate.cmake.in file, I'd like to have variables
such as ${${PROJECT_NAME}_VERSION}. In ${}-syntax, the nesting is
recognized properly, and this string would be replaced by, e.g.,
2.1.
I know need to have ${}-variables in the output file, so I tried to
switch to the @-syntax.
then I guess you use configure_file(... @ONLY)
Replacing the above line by
@@PROJECT_NAME@_VERSION@
doesn't work however: The output file contains
@Myproject_VERSION@
i.e., only the inner variable was replaced.
How to fix this?
May be it's a feature not a bug.
(honestly I don't know but I guess the behavior has probably been here
for ages so that people may rely on it)
Did you try protecting the $ that needs to be with \$
Or
set(PDOLLAR $) and use ${PDOLLAR}
--
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--
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] nested replacement with @@
2013/4/10 Eric Noulard eric.noul...@gmail.com 2013/4/10 Nico Schlömer nico.schloe...@gmail.com Replacing the above line by @@PROJECT_NAME@_VERSION@ doesn't work however: The output file contains @Myproject_VERSION@ i.e., only the inner variable was replaced. How to fix this? May be it's a feature not a bug. (honestly I don't know but I guess the behavior has probably been here for ages so that people may rely on it) Did you realize you post almost the same question on August 2012; http://www.cmake.org/pipermail/cmake/2012-August/051503.html and some times after that somebody else stepped-in: http://www.cmake.org/pipermail/cmake/2012-September/052016.html none of those messages did seem to get answered?? Any Kitware guy wanting to step in order to teach us whether if it is a feature or a bug? -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- 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] nested replacement with @@
Nico,
I had this same problem at one point in time, but was able to change it to the
${...} syntax which works beautifully. I know that you cannot use this syntax,
but I will tell you that I did find a work-around for the nested @...@ syntax.
The workaround is to run configure_file on the file twice. The nested @...@
symbols will always be replaced from the inside out which is the behavior that
you want, you just have to run configure_file on the file for as many nests
that you have. If the deepest nest you have is two nests, then you only need to
run configure_file twice. I know this is kind of a kludge to fix it, but it
does work from my experience...
Hope this helps...
Eric
-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On
Behalf Of Nico Schlömer
Sent: Wednesday, April 10, 2013 12:55 PM
To: cmake
Subject: [CMake] nested replacement with @@
Hi all,
in a ProjectContfigTemplate.cmake.in file, I'd like to have variables such as
${${PROJECT_NAME}_VERSION}. In ${}-syntax, the nesting is recognized
properly, and this string would be replaced by, e.g., 2.1.
I know need to have ${}-variables in the output file, so I tried to switch to
the
@-syntax. Replacing the above line by
@@PROJECT_NAME@_VERSION@
doesn't work however: The output file contains
@Myproject_VERSION@
i.e., only the inner variable was replaced.
How to fix this?
Cheers,
Nico
--
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] nested replacement with @@
Another workaround is to make an intermediate variable in the CMakeLists.txt
file and use this intermediate variable from the .in file. That elminates the
nested @@'s.
Clint
On Wednesday, April 10, 2013 07:51:03 PM Eric Clark wrote:
Nico,
I had this same problem at one point in time, but was able to change it to
the ${...} syntax which works beautifully. I know that you cannot use this
syntax, but I will tell you that I did find a work-around for the nested
@...@ syntax. The workaround is to run configure_file on the file twice.
The nested @...@ symbols will always be replaced from the inside out which
is the behavior that you want, you just have to run configure_file on the
file for as many nests that you have. If the deepest nest you have is two
nests, then you only need to run configure_file twice. I know this is kind
of a kludge to fix it, but it does work from my experience...
Hope this helps...
Eric
-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On
Behalf Of Nico Schlömer
Sent: Wednesday, April 10, 2013 12:55 PM
To: cmake
Subject: [CMake] nested replacement with @@
Hi all,
in a ProjectContfigTemplate.cmake.in file, I'd like to have variables such
as ${${PROJECT_NAME}_VERSION}. In ${}-syntax, the nesting is recognized
properly, and this string would be replaced by, e.g., 2.1.
I know need to have ${}-variables in the output file, so I tried to switch
to the @-syntax. Replacing the above line by
@@PROJECT_NAME@_VERSION@
doesn't work however: The output file contains
@Myproject_VERSION@
i.e., only the inner variable was replaced.
How to fix this?
Cheers,
Nico
--
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
--
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://www.cmake.org/mailman/listinfo/cmake
[CMake] clear compile flags for a file
So I have the same problem as the person in this old thread: http://www.cmake.org/pipermail/cmake/2009-August/031671.html I want to add some compile flags (currently using add_definitions) but they mess up the rc.exe resource compiler. Doing something like: set_source_files_properties(hipchat.rc PROPERTIES COMPILE_DEFINITIONS )set_source_files_properties(hipchat.rc PROPERTIES COMPILE_FLAGS ) doesn't work, I guess set_source_file_properties is only appending. setting CMAKE_CXX_FLAGS didn't seem to work at all. -- 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] clear compile flags for a file
On Wed, Apr 10, 2013 at 1:37 PM, Ian Monroe i...@monroe.nu wrote: So I have the same problem as the person in this old thread: http://www.cmake.org/pipermail/cmake/2009-August/031671.html I want to add some compile flags (currently using add_definitions) but they mess up the rc.exe resource compiler. Doing something like: set_source_files_properties(hipchat.rc PROPERTIES COMPILE_DEFINITIONS )set_source_files_properties(hipchat.rc PROPERTIES COMPILE_FLAGS ) doesn't work, I guess set_source_file_properties is only appending. setting CMAKE_CXX_FLAGS didn't seem to work at all. Ok I figured out you need to pass CMAKE_CXX_FLAGS a string. So now I have it all working. I still wonder if the state-of-the-art has changed since 2009. Is there a way to clear definitions from a file? -- 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] Discovering ExternalProject library dependencies?
Hello, Is there a convenient way to have CMake detect at build time additional libraries that need to be linked for an external project to work? For example, suppose I have ExternalProject_Add(Foo ...args...) which builds libfoo.a (which is an autotools package). Depending on the system on which libfoo is built, sometimes linking against it also requires -labc, and other times it requires -lxyz. For normal users of libfoo, it writes out a pkg-config file that sets an appropriate Libs: ... line. I'm trying to figure out how to handle this in CMake. Possible options: 1. Have my project repeat the checks that libfoo does to discover whether -labc or -lxyz is required. This is clearly doable but doesn't seem like the right answer (duplicated checks, what if they change in the future, etc.). 2. Use FindPkgConfig *after* Foo is built. I don't know if this is possible. 3. Use file(STRINGS ...) on the .pc file that Foo writes out and parse out the Libs line manually. Does anyone have any suggestions on the right thing to do here? Thanks, John -- 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-commits] CMake branch, next, updated. v2.8.10.2-2746-g98f389e
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 98f389eb19d3f56de0c8d68d50be7a3be6a3577a (commit)
via 5a5e0fa9d35ea49ef9d31993ab415fc0e390e8b0 (commit)
via a5b39fd3c68b61a33957b03807db14b02cdea4c4 (commit)
via a96452ec066933974518acf015e9494f3b0834c5 (commit)
via 4336fadff05b4e490ff48282e1b9e30c89de5d39 (commit)
via 88073c8e08302c9cea309d9753c11dc01a7d5f1c (commit)
from f3b4525969f174fe00d5f6ed4168e51e644e5922 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=98f389eb19d3f56de0c8d68d50be7a3be6a3577a
commit 98f389eb19d3f56de0c8d68d50be7a3be6a3577a
Merge: f3b4525 5a5e0fa
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Wed Apr 10 12:15:14 2013 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Apr 10 12:15:14 2013 -0400
Merge topic 'fix-clear-INCLUDE_DIRECTORIES-prop' into next
5a5e0fa Fix clearing of the INCLUDE_DIRECTORIES DIRECTORY property.
a5b39fd CMake Nightly Date Stamp
a96452e CMake Nightly Date Stamp
4336fad CMake Nightly Date Stamp
88073c8 CMake Nightly Date Stamp
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5a5e0fa9d35ea49ef9d31993ab415fc0e390e8b0
commit 5a5e0fa9d35ea49ef9d31993ab415fc0e390e8b0
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Wed Apr 10 18:12:56 2013 +0200
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Wed Apr 10 18:12:56 2013 +0200
Fix clearing of the INCLUDE_DIRECTORIES DIRECTORY property.
This was broken by commit 18a3195a (Keep track of INCLUDE_DIRECTORIES
as a vector of structs., 2012-11-19).
diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx
index 25ccbc7..47a6d2e 100644
--- a/Source/cmMakefile.cxx
+++ b/Source/cmMakefile.cxx
@@ -3458,6 +3458,10 @@ void cmMakefile::SetProperty(const char* prop, const
char* value)
if (propname == INCLUDE_DIRECTORIES)
{
this-IncludeDirectoriesEntries.clear();
+ if (!value)
+{
+return;
+}
cmListFileBacktrace lfbt;
this-GetBacktrace(lfbt);
this-IncludeDirectoriesEntries.push_back(
diff --git a/Tests/IncludeDirectories/CMakeLists.txt
b/Tests/IncludeDirectories/CMakeLists.txt
index 60f5e5e..8a60f17 100644
--- a/Tests/IncludeDirectories/CMakeLists.txt
+++ b/Tests/IncludeDirectories/CMakeLists.txt
@@ -47,3 +47,14 @@ else()
endif()
add_subdirectory(TargetIncludeDirectories)
+
+set_property(DIRECTORY PROPERTY INCLUDE_DIRECTORIES ${CMAKE_BINARY_DIR})
+get_property(propContent DIRECTORY PROPERTY INCLUDE_DIRECTORIES)
+if (NOT propContent STREQUAL ${CMAKE_BINARY_DIR})
+ message(SEND_ERROR Setting DIRECTORY property failed.)
+endif()
+set_property(DIRECTORY PROPERTY INCLUDE_DIRECTORIES)
+get_property(propContentAfter DIRECTORY PROPERTY INCLUDE_DIRECTORIES)
+if (NOT propContentAfter STREQUAL )
+ message(SEND_ERROR Clearing DIRECTORY property failed.)
+endif()
---
Summary of changes:
Source/CMakeVersion.cmake |2 +-
Source/cmMakefile.cxx |4
Tests/IncludeDirectories/CMakeLists.txt | 11 +++
3 files changed, 16 insertions(+), 1 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.10.2-985-g6bfa3d8
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 6bfa3d8668ecbc0c7b57f1c0fdcd56ba177a00b6 (commit) from c6253fba415238bc85f4b74365a7d6ebac1735e7 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6bfa3d8668ecbc0c7b57f1c0fdcd56ba177a00b6 commit 6bfa3d8668ecbc0c7b57f1c0fdcd56ba177a00b6 Author: Kitware Robot kwro...@kitware.com AuthorDate: Thu Apr 11 00:01:08 2013 -0400 Commit: Kitware Robot kwro...@kitware.com CommitDate: Thu Apr 11 00:01:08 2013 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 7b07228..c4c987d 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -2,5 +2,5 @@ set(CMake_VERSION_MAJOR 2) set(CMake_VERSION_MINOR 8) set(CMake_VERSION_PATCH 10) -set(CMake_VERSION_TWEAK 20130410) +set(CMake_VERSION_TWEAK 20130411) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
