Re: [cmake-developers] How to cleanly get rid of CMake specific properties?
2012/2/18 Eric Noulard : > 2012/2/18 Alexander Neundorf : >> On Saturday 18 February 2012, Eric Noulard wrote: >>> Hi all, >>> >>> I'm pursuing my quest for a better CPack doc. >>> First set of modifications are in master: >>> cpack --help-command-xxx >>> cpack --help-variable-xxx >>> works. >>> >>> However variables are somehow "problematic" because I get all the >>> properties defined for CMake in the doc because variables are a >>> special kind of properties. >>> >>> CPack (or CTest) is using a instance of cmake object which does: >>> >>> this->InitializeProperties(); >>> >>> in its constructor >>> so that I end up with a lot more properties in "full doc" >>> i.e. in >>> cpack --help-full >>> >>> Than I thought I shall. >>> Now there is two options: >>> >>> 1) Avoid InitializeProperties(); in cmake object constructor and do >>> that elsewhere >>> for CMake and nowhere for CTest and CPack. >>> >>> 2) Let CTest and CPack keep the CMake inherited properties and filter out >>> the unwaned CMake specific section in the doc. >>> >>> 1) is definitely easier but raise a question: >>> Do CTest and CPack NEED the cmake property definition? >>> Is this a wanted behavior or just an oversight? >>> i.e. is set_property(...) supposed to work in a ctest or cpack >>> loaded script? >>> >>> 2) is doable but require more work. >>> >>> in the same way should the "standard" variable doc section be inherited >>> from CMake to CTest/CPack? >>> >>> try (I know it's not supposed to work but nevertheless): >>> ctest --help-variable-list >>> >>> and you'll see what I mean. >> >> 2) sounds like a hack. If the properties are there, there should be a reason >> for it, and then they should also appear in the documentation. > > Agreed but it strange to have documentation for > ALLOW_DUPLICATE_CUSTOM_TARGETS > RULE_LAUNCH_COMPILE > COMPILE_DEFINITIONS > etc... > > for either CPack or CTest. > nevertheless they ARE currently defined in the CMake script > interpreter used by CTest or CPack > because as I said they are defined in the cmake object constructor. > They do not appear in the CTest doc because --help-variable is not implemented > they do now in cpack because of that. > > Concerning CPack I'm pretty sure no part of CPack code uses > CMake inherited properties, cpack's cmake interpreter is not supposed > to load > > For CTest I doubt it but the fact is I don't really know. > > A small test of CMake in scripting mode > (see script attached > try it with > cmake -P scriptable.cmake) > tells me some properties may be useful but may be not all of them... > > Your opinion? Just a precision, I did test CMake in script mode because it is basically the mode used by CTest and CPack. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.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
[cmake-developers] [CMake 0012982]: Misdetects endianess on mipsel
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=12982 == Reported By:Modestas Vainius Assigned To: == Project:CMake Issue ID: 12982 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2012-02-19 06:39 EST Last Modified: 2012-02-19 06:39 EST == Summary:Misdetects endianess on mipsel Description: Hello, it appears that CMake misdetects endianess on mipsel (MIPS little endian [1]) which triggers a failure of cmIML_ABI_ENDIAN_ID test on that architecture. See full build log [2] for more details. As far as I know, MIPS machines are biendian hence they can run both big endian (Debian mips architecture) and little endian (Debian mipsel architecture) kernels. Predefined macro dumps are in additional information section. Preliminary patch is attached. [1] http://wiki.debian.org/ArchitectureSpecificsMemo [2] https://buildd.debian.org/status/fetch.php?pkg=cmake&arch=mipsel&ver=2.8.7-1&stamp=1329590245 Additional Information: -- mipsel (little endian) -- #define __DBL_MIN_EXP__ (-1021) #define __HQ_FBIT__ 15 #define __UINT_LEAST16_MAX__ 65535 #define __SFRACT_IBIT__ 0 #define __FLT_MIN__ 1.1754943508222875e-38F #define __UFRACT_MAX__ 0XP-16UR #define __UINT_LEAST8_TYPE__ unsigned char #define __DQ_FBIT__ 63 #define __INTMAX_C(c) c ## LL #define __ULFRACT_FBIT__ 32 #define __SACCUM_EPSILON__ 0x1P-7HK #define __CHAR_BIT__ 8 #define __USQ_IBIT__ 0 #define __UINT8_MAX__ 255 #define __ACCUM_FBIT__ 15 #define __WINT_MAX__ 4294967295U #define R3000 1 #define __USFRACT_FBIT__ 8 #define __ORDER_LITTLE_ENDIAN__ 1234 #define __SIZE_MAX__ 4294967295U #define __WCHAR_MAX__ 2147483647 #define __LACCUM_IBIT__ 32 #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1 #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1 #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1 #define __DBL_DENORM_MIN__ ((double)4.9406564584124654e-324L) #define __FLT_EVAL_METHOD__ 0 #define __unix__ 1 #define __LLACCUM_MAX__ 0X7FFFP-31LLK #define __FRACT_FBIT__ 15 #define _MIPS_ISA _MIPS_ISA_MIPS2 #define __UINT_FAST64_MAX__ 18446744073709551615ULL #define __SIG_ATOMIC_TYPE__ int #define __UACCUM_FBIT__ 16 #define __LANGUAGE_C 1 #define __DBL_MIN_10_EXP__ (-307) #define __FINITE_MATH_ONLY__ 0 #define _MIPS_TUNE "mips32" #define _ABIO32 1 #define __LFRACT_IBIT__ 0 #define __GNUC_PATCHLEVEL__ 2 #define __LFRACT_MAX__ 0X7FFFP-31LR #define __UINT_FAST8_MAX__ 255 #define __DEC64_MAX_EXP__ 385 #define __INT8_C(c) c #define __UINT_LEAST64_MAX__ 18446744073709551615ULL #define __SA_FBIT__ 15 #define __SHRT_MAX__ 32767 #define __LDBL_MAX__ 1.7976931348623157e+308L #define __FRACT_MAX__ 0X7FFFP-15R #define __UFRACT_FBIT__ 16 #define __UFRACT_MIN__ 0.0UR #define __UINT_LEAST8_MAX__ 255 #define __mips_abicalls 1 #define __LANGUAGE_C__ 1 #define __UINTMAX_TYPE__ long long unsigned int #define __LLFRACT_EPSILON__ 0x1P-63LLR #define __linux 1 #define __DEC32_EPSILON__ 1E-6DF #define __unix 1 #define __UINT32_MAX__ 4294967295U #define __ULFRACT_MAX__ 0XP-32ULR #define __TA_IBIT__ 64 #define __LDBL_MAX_EXP__ 1024 #define __WINT_MIN__ 0U #define __MIPSEL__ 1 #define __linux__ 1 #define __ULLFRACT_MIN__ 0.0ULLR #define __SCHAR_MAX__ 127 #define __WCHAR_MIN__ (-__WCHAR_MAX__ - 1) #define __INT64_C(c) c ## LL #define __DBL_DIG__ 15 #define __LLACCUM_MIN__ (-0X1P31LLK-0X1P31LLK) #define __SIZEOF_INT__ 4 #define __SIZEOF_POINTER__ 4 #define __USACCUM_IBIT__ 8 #define __USER_LABEL_PREFIX__ #define __STDC_HOSTED__ 1 #define __LDBL_HAS_INFINITY__ 1 #define __LFRACT_MIN__ (-0.5LR-0.5LR) #define __mips_fpr 32 #define __HA_IBIT__ 8 #define __TQ_IBIT__ 0 #define __FLT_EPSILON__ 1.1920928955078125e-7F #define __mips__ 1 #define __USFRACT_IBIT__ 0 #define __LDBL_MIN__ 2.2250738585072014e-308L #define __FRACT_MIN__ (-0.5R-0.5R) #define __DEC32_MAX__ 9.99E96DF #define __DA_IBIT__ 32 #define MIPSEL 1 #define __INT32_MAX__ 2147483647 #define __UQQ_FBIT__ 8 #define __SIZEOF_LONG__ 4 #define __UACCUM_MAX__ 0XP-16UK #define __UINT16_C(c) c #define __DECIMAL_DIG__ 17 #define __LFRACT_EPSILON__ 0x1P-31LR #define __ULFRACT_MIN__ 0.0ULR #define __gnu_linux__ 1 #define __LDBL_HAS_QUIET_NAN__ 1 #define __ULACCUM_IBIT__ 32 #define __UACCUM_EPSILON__ 0x1P-16UK #define __GNUC__ 4 #define __ULLACCUM_MAX__ 0XP-32ULLK #define __HQ_IBIT__ 0 #define __FLT_HAS_DENORM__ 1 #define __SIZEOF_LONG_DOUBLE__ 8 #
Re: [cmake-developers] Ninja generator on Windows
On 19.02.2012 07:21, Peter Collingbourne wrote: This caused custom commands to be double encoded, causing a test failure on *nix. I reverted part of your changes to fix the test failures and also had a look at implementing the escaping rules correctly. With the changes I made, I was able to configure CMake successfully using the token-splitter branch. I found that on Windows (on my machine at least), some try_compile runs were non-deterministic, and this caused build failures in CMake. I also encountered the issue Oscar mentioned in the other thread regarding the pdb file being locked (maybe the two issues are related). But I was able to successfully compile most of LLVM/Clang on Windows. Great you found the time have a look at this. The token-splitter was broken, some unit tests failed. I've fixed it, when updating you need to reset --hard. Maybe this helps. I also uploaded a new installer: http://sourceforge.net/projects/cmakescript/files/cmake-2.8.7.20120202-win32-x86-Ninja.exe When cmake/ninja doesn't start installing the runtime for MSVC10 should help: http://www.microsoft.com/download/en/details.aspx?id=8328 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
Re: [cmake-developers] ninja spaces in the path do not work on linux
2012/2/19 Peter Collingbourne > On Fri, Feb 17, 2012 at 09:16:31PM +0100, Nicolas Desprès wrote: > > 2012/2/17 Bill Hoffman > > > > > On 2/17/2012 12:26 PM, Nicolas Desprès wrote: > > > > > >> > > >> I think it is a bug in the generator which do not escape the space > > >> properly using the $ character as supported by Ninja. > > >> > > >> -- > > >> Nicolas Desprès > > >> > > >> Will you be able to fix that? > > > > > > > I think yes. It is just a matter of time. My weekend is already > overloaded. > > I'll try to do it. If Peter or someone else in the community comes up > with > > a patch before me everybody would be happy :-) > > I decided to look into escaping rules this weekend. Now with the > code on the ninja-generator branch, CMake can build itself with both > source and build directories containing spaces, and pass all tests. > LLVM/Clang can also build with both directory names containing spaces. > > Thanks for this Peter. I have just tried the new stage/ninja-generator branch with spaces in both the source and the binary directory and I got this result for the test suite: The following tests FAILED: 83 - CPackComponents (Failed) 217 - CMake.CheckSourceTree (Failed) Note that on my Linux box: - CMake.CheckSourceTree always fail even on the master branch (I never tried to understand why). - CPackComponents fails only when there are spaces but the Unix Makefiles generator has the same issue. Cheers, -- Nicolas Desprès -- 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 spaces in the path do not work on linux
Le 19 février 2012 15:19, Nicolas Desprès a écrit : > > Thanks for this Peter. I have just tried the new stage/ninja-generator > branch with spaces in both the source and the binary directory and I got > this result for the test suite: > > The following tests FAILED: > 83 - CPackComponents (Failed) > 217 - CMake.CheckSourceTree (Failed) > > Note that on my Linux box: > - CMake.CheckSourceTree always fail even on the master branch (I never tried > to understand why). Because you should have some local modification in the source tree. Try: ctest -V -R CMake.CheckSourceTree and you'll possibly get an explanation like: 232: additions='0' 232: conflicts='0' 232: modifications='0' 232: nonadditions='1' ... 232: CMake Error at CheckSourceTreeTest.cmake:422 (message): 232: test fails: local source tree non-additions: use git add before committing, 232: or remove the files from the source tree > - CPackComponents fails only when there are spaces but the Unix Makefiles > generator has the same issue. I think this should not happen, normally CPack generators that cannot handle space in build tree (like CPackRPM) should be filtered out. In order to know the culprit same method applies here: ctest -V -R "^CPackComponents$" (you can do ctest -V -R CPackComponents but you'll get more tests) -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.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] find_package error wording
Hi, I must have missed something here. On Friday, February 17, 2012 13:16:42 Brad King wrote: > On 2/17/2012 12:09 PM, Alexander Neundorf wrote: > > But another significant part of the reason is probably that beside > > upstreaming a module to cmake, there is no other "official" way to > > distribute Find- modules. So if somebody wrote a libblub, it is a > > relatively obvious choice to install FindBlub.cmake as part of the > > library, so that whoever uses Blub, also has FindBlub.cmake available. > > If the Blub project is built with CMake then there should be no FindBlub > for it at all. It should just install BlubConfig.cmake and be done. > Perhaps your work to make the files easier to write will help with that. I think this is a good point. > > The only reason to distribute FindBlub for a CMake-aware project is > to wrap up find_package NO_MODULE to produce a nicer message, but that > is totally optional. If a project does want to distribute one for > reference it should go in the -doc package, not in -dev, and should be > put in share/doc/blub or the distro's equivalent. Good point. > > > Additionally, the Config.cmake file feature of cmake is still relatively > > unknown. It could use some more PR ;-) > > I'll have to think about how to deal with that. Also relevant. The below seems to be hiding the config files stuff as you wrote. > > > By having to use NO_MODULE, or the other way round, if by not using > > NO_MODULE it is clear to cmake that a Find-module is needed, it could > > then print > > something like: > Adding the explicit "MODULE" mode keyword could help with that. > > >> > - search for FindFoo.cmake, use if found > >> > - if not found, check new policy setting > >> > - if not set, warn and follow OLD behavior > >> > - if set to OLD, enter config mode and use current error if > >> > not found - if set to NEW, present error about no FindFoo > >> > in module path> > > Yes, exactly. > > We can adjust it slightly to avoid the policy warning when FooConfig > is found and Foo_DIR is set: > > - search for FindFoo.cmake, use if found > - if not found, check new policy setting > - if not set, enter config mode and emit both the policy warning > and the current error if not found > - if set to OLD, enter config mode and use current error if not found > - if set to NEW, present error about no FindFoo in module path > > One problem with the policy is that it favors module mode as the "normal" > case and makes "config" mode look like something special. Yes. > That will > not help with the perception that the latter is preferred. Yes. However, your suggestion above seems to indicate that that is exactly what's being done? That will make this an error: cmake_required_version(2.8.8) find_package(Qt5Core) Instead this more noisy version would need to be used: cmake_required_version(2.8.8) find_package(Qt5Core CONFIG_MODE) I think that this should work just fine: cmake_required_version(2.8.8) find_package(Qt5Core) And to make Alex's use case satisfied, add a variable for strictness to make this an error: cmake_required_version(2.8.8) set(CMAKE_FIND_PACKAGE_EXPLICIT_MODE ON) find_package(Qt5Core) which Alex can set somewhere in KDE. The main problem is lack of education about config files. That can be solved in the future, so we should make sure that the requirements can be 'clean' for the future. When at some future point KDE developers (and others) are aware of config files, KDE won't need set(CMAKE_FIND_PACKAGE_EXPLICIT_MODE ON) and it can be removed. I prefer KDE to require set(CMAKE_FIND_PACKAGE_EXPLICIT_MODE) rather than changing the default behaviour of CMake (to produce errors) because the former is future proof. 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 spaces in the path do not work on linux
2012/2/19 Eric Noulard > Le 19 février 2012 15:19, Nicolas Desprès a > écrit : > > > > Thanks for this Peter. I have just tried the new stage/ninja-generator > > branch with spaces in both the source and the binary directory and I got > > this result for the test suite: > > > > The following tests FAILED: > > 83 - CPackComponents (Failed) > > 217 - CMake.CheckSourceTree (Failed) > > > > Note that on my Linux box: > > - CMake.CheckSourceTree always fail even on the master branch (I never > tried > > to understand why). > > Because you should have some local modification in the source tree. > Try: > ctest -V -R CMake.CheckSourceTree > > and you'll possibly get an explanation like: > 232: additions='0' > 232: conflicts='0' > 232: modifications='0' > 232: nonadditions='1' > ... > 232: CMake Error at CheckSourceTreeTest.cmake:422 (message): > 232: test fails: local source tree non-additions: use git add before > committing, > 232: or remove the files from the source tree > > True I had some untracked files. Thanks it works now :) > > - CPackComponents fails only when there are spaces but the Unix > Makefiles > > generator has the same issue. > > I think this should not happen, normally CPack generators that cannot > handle space in build tree (like CPackRPM) should be filtered out. > > In order to know the culprit same method applies here: > ctest -V -R "^CPackComponents$" > > (you can do ctest -V -R CPackComponents > but you'll get more tests) > I open a new discussion thread "CPackComponents fails with spaces in paths" cause it is off-topic. Thanks, -- Nicolas Desprès -- 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] making exports first-class (was: Making Config.cmake files easier to write)
Brad King wrote: > If anyone is interested in working on something like this the C++ changes > you mention would need to make exports recorded by either export() or > install(EXPORT) into first-class objects. A major missing feature from > them right now is having multiple logical exports with dependencies. > Currently an export must include the transitive closure of its own > dependencies. If instead they were first class objects in CMake then > then the dependencies of one export could be satisfied by an export-level > dependency on another export. Just to link all this together: http://public.kitware.com/Bug/view.php?id=12588 Discussion: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/2285/focus=2299 (It would be helpful to reopen the bug and link to the mailing list threads there) -- 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] CPackComponents fails with spaces in paths
Hi, The CPackComponents test fails on master where there is a space in the source tree. Here I think the trace: $ ctest -V -R 'CPackComponents$' == UpdateCTestConfiguration from :/home/despre_n/tmp/cmake space/_build/DartConfiguration.tcl Parse Config file:/home/despre_n/tmp/cmake space/_build/DartConfiguration.tcl Add coverage exclude regular expressions. Add coverage exclude: XCode Add coverage exclude: Kdevelop Add coverage exclude: /Source/(cm|kw)sys/ Add coverage exclude: /CMakeFiles/CMakeTmp/ Add coverage exclude: [A-Za-z]./[Qq]t/qt-.+-opensource-src UpdateCTestConfiguration from :/home/despre_n/tmp/cmake space/_build/DartConfiguration.tcl Parse Config file:/home/despre_n/tmp/cmake space/_build/DartConfiguration.tcl Test project /home/despre_n/tmp/cmake space/_build Constructing a list of tests Guessing configuration NoConfig Done constructing a list of tests Checking test dependency graph... Checking test dependency graph end test 89 Start 89: CPackComponents 89: Test command: /home/despre_n/tmp/cmake\ space/_build/bin/ctest "--build-and-test" "/home/despre_n/tmp/cmake space/Tests/CPackComponents" "/home/despre_n/tmp/cmake space/_build/Tests/CPackComponents" "--build-generator" "Unix Makefiles" "--build-project" "CPackComponents" "--build-makeprogram" "/usr/bin/make" "--build-two-config" "--build-target" "package" "--build-options" "-DCPACK_BINARY_DEB:BOOL=ON" "-DCPACK_BINARY_RPM:BOOL=ON" "-DCPACK_BINARY_NSIS:BOOL=ON" "--graphviz=CPackComponents.dot" "--test-command" "/home/despre_n/tmp/cmake space/_build/bin/cmake" "-DCPackComponents_BINARY_DIR:PATH=/home/despre_n/tmp/cmake space/_build/Tests/CPackComponents" "-P" "/home/despre_n/tmp/cmake space/Tests/CPackComponents/VerifyResult.cmake" 89: Test timeout computed to be: 1500 89: Generate graphviz: /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackComponents.dot 89: Writing /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackComponents.dot.mylib... 89: Writing /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackComponents.dot.mylibapp... 89: Writing /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackComponents.dot.mylib.dependers... 89: Writing /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackComponents.dot.mylibapp.dependers... 89: Writing /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackComponents.dot... 89: Generate graphviz: /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackComponents.dot 89: Writing /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackComponents.dot.mylib... 89: Writing /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackComponents.dot.mylibapp... 89: Writing /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackComponents.dot.mylib.dependers... 89: Writing /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackComponents.dot.mylibapp.dependers... 89: Writing /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackComponents.dot... 89: Internal cmake changing into directory: /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents 89: CMake output == 89: Configuring 89: Configuring done 89: Generating 89: Generating done 89: Build files have been written to: /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents 89: Configuring 89: Configuring done 89: Generating 89: Generating done 89: Build files have been written to: /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents 89: End CMake output == 89: Change Dir: /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents 89: 89: Run Clean Command:/usr/bin/make "clean" 89: 89: Run Build Command:/usr/bin/make "package" 89: [ 50%] Building CXX object CMakeFiles/mylib.dir/mylib.cpp.o 89: Linking CXX static library libmylib.a 89: [ 50%] Built target mylib 89: [100%] Building CXX object CMakeFiles/mylibapp.dir/mylibapp.cpp.o 89: Linking CXX executable mylibapp 89: [100%] Built target mylibapp 89: Run CPack packaging tool... 89: CMake Warning (dev) at /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackConfig.cmake:54 (SET): 89: Syntax error in cmake code at 89: 89: /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents/CPackConfig.cmake:54 89: 89: when parsing string 89: 89: C:\Program Files\CMake Tests Install Root 89: 89: Invalid escape sequence \P 89: 89: Policy CMP0010 is not set: Bad variable reference syntax is an error. Run 89: "cmake --help-policy CMP0010" for policy details. Use the cmake_policy 89: command to set the policy and suppress this warning. 89: This warning is for project developers. Use -Wno-dev to suppress it. 89: 89: CPack: Create package using DEB 89: CPack: Install projects 89: CPack: - Run preinstall target for: CPackComponents 89: CPack: - Install project: CPackComponents 89: CPack: Create package 89: CPack: - package: /home/despre_n/tmp/cmak
Re: [cmake-developers] find_package error wording
On Sunday 19 February 2012, Stephen Kelly wrote: > Hi, > > I must have missed something here. > > On Friday, February 17, 2012 13:16:42 Brad King wrote: > > On 2/17/2012 12:09 PM, Alexander Neundorf wrote: > > > But another significant part of the reason is probably that beside > > > upstreaming a module to cmake, there is no other "official" way to > > > distribute Find- modules. So if somebody wrote a libblub, it is a > > > relatively obvious choice to install FindBlub.cmake as part of the > > > library, so that whoever uses Blub, also has FindBlub.cmake available. > > > > If the Blub project is built with CMake then there should be no FindBlub > > for it at all. It should just install BlubConfig.cmake and be done. > > Perhaps your work to make the files easier to write will help with that. > > I think this is a good point. Yes. > > The only reason to distribute FindBlub for a CMake-aware project is > > to wrap up find_package NO_MODULE to produce a nicer message, but that > > is totally optional. If a project does want to distribute one for > > reference it should go in the -doc package, not in -dev, and should be > > put in share/doc/blub or the distro's equivalent. > > Good point. ...but nobody does it or knows it. > > > Additionally, the Config.cmake file feature of cmake is still > > > relatively unknown. It could use some more PR ;-) > > > > I'll have to think about how to deal with that. > > Also relevant. The below seems to be hiding the config files stuff as you > wrote. No, by making CONFIG_MODE explicit it is exactly not hidden anymore, but becomes visible. > > > By having to use NO_MODULE, or the other way round, if by not using > > > NO_MODULE it is clear to cmake that a Find-module is needed, it could > > > then print > > > > > something like: > > Adding the explicit "MODULE" mode keyword could help with that. > > > > >> > - search for FindFoo.cmake, use if found > > >> > - if not found, check new policy setting > > >> > - if not set, warn and follow OLD behavior > > >> > - if set to OLD, enter config mode and use current error if > > >> > not found - if set to NEW, present error about no FindFoo > > >> > in module path> > > > > > > Yes, exactly. > > > > We can adjust it slightly to avoid the policy warning when FooConfig > > > > is found and Foo_DIR is set: > > - search for FindFoo.cmake, use if found > > - if not found, check new policy setting > > - if not set, enter config mode and emit both the policy warning > > > > and the current error if not found > > > > - if set to OLD, enter config mode and use current error if not found > > - if set to NEW, present error about no FindFoo in module path > > > > One problem with the policy is that it favors module mode as the "normal" > > case and makes "config" mode look like something special. > > Yes. Right now the perception is that there is the Module-mode. ...and some people may have heard of some weird config files. Putting both modes on the same level (MODULE_MODE vs. CONFIG_MODE) I hope should help with that. > > That will> > not help with the perception that the latter is preferred. > > Yes. > > However, your suggestion above seems to indicate that that is exactly > what's being done? > > That will make this an error: > > cmake_required_version(2.8.8) > find_package(Qt5Core) > > Instead this more noisy version would need to be used: > > cmake_required_version(2.8.8) > find_package(Qt5Core CONFIG_MODE) Yes. And this is good. Then the error message is "Could not find config file". Above it has to guess, and the developers will think that FindQt5.cmake is missing. How should they know that Qt5 ships Qt5Config.cmake files ? We always had FindFoo.cmake files for everything, including FindQt4.cmake. They will not think "oh, probably a Qt5Config.cmake could not be found". I am 99% sure with this. Somebody complained on google+ that cmake is a mess. If you don't know what to make of an error message, this won't help the perception. > I think that this should work just fine: > > cmake_required_version(2.8.8) > find_package(Qt5Core) > > And to make Alex's use case satisfied, add a variable for strictness to > make this an error: > > cmake_required_version(2.8.8) > set(CMAKE_FIND_PACKAGE_EXPLICIT_MODE ON) > find_package(Qt5Core) > > which Alex can set somewhere in KDE. > > The main problem is lack of education about config files. That can be > solved in the future, so we should make sure that the requirements can be > 'clean' for the future. When at some future point KDE developers (and > others) are aware of config files, KDE won't need > set(CMAKE_FIND_PACKAGE_EXPLICIT_MODE ON) and it can be removed. Why push that further into the future, right now where we are about to create dozens of config files ? If we create dozens of config files, developers will see the message "could not find Find-module or config file" and they will complain that the project is b
[cmake-developers] GenerateExportHeader gcc version test failure?
Hi, In the last few days something changed to make the GenerateExportHeader GCC version check fail: http://open.cdash.org/buildSummary.php?buildid=2016288 Any idea what would cause that? It must be one of these: http://open.cdash.org/viewUpdate.php?buildid=2016288 (as a side note, I find http://www.cmake.org/Bug/view.php?id=12957 interesting - I think that was a cause of many of the errors I had when trying to get GenerateExportHeader working on windows and is the reason I use an incrememted counter in the unit tests for it.) 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] find_package module-only policy (was: find_package error wording)
On 2/18/2012 10:43 AM, Alexander Neundorf wrote:
> This is now in the branch FindPackage_MODULE_MODE_Policy on stage.
> I still have to add tests.
Thanks for the prototype. I'm not promising acceptance yet
but it is a good reference for discussion. I'm going to
continue the discussion over on Stephen's response in this
thread.
> I think with this new policy MODULE_MODE should not be considered the "simple
> signature" and NO_MODULE the "full signature" anymore, but both with equal
> rights.
It used to be one signature but IIRC you asked me to break out the
reduced signature since that is all people need most of the time.
After thinking about the new _MODE options more I think calling
them just "MODULE" and "CONFIG" is better. The former is very
clearly the opposite of NO_MODULE, and the latter reads well:
find_package(Foo CONFIG) # find Foo's package "config" file
I do not think the similarity of "CONFIG" to the existing "CONFIGS"
is a problem because the latter implies the former anyway so they
never need to be used at the same time. The latter reads well too:
find_package(Foo CONFIGS FooConfig.cmake)
# (Finds "FooConfig.cmake" from package Foo)
# ("CONFIGS" is similar to "NAMES" in find_library)
-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] CPackComponents fails with spaces in paths
Le 19 février 2012 16:07, Nicolas Desprès a écrit : > Hi, > > The CPackComponents test fails on master where there is a space in the > source tree. Here I think the trace: > > $ ctest -V -R 'CPackComponents$' > > == > UpdateCTestConfiguration from :/home/despre_n/tmp/cmake > space/_build/DartConfiguration.tcl > Parse Config file:/home/despre_n/tmp/cmake > space/_build/DartConfiguration.tcl > Add coverage exclude regular expressions. > Add coverage exclude: XCode > Add coverage exclude: Kdevelop > Add coverage exclude: /Source/(cm|kw)sys/ > Add coverage exclude: /CMakeFiles/CMakeTmp/ > Add coverage exclude: [A-Za-z]./[Qq]t/qt-.+-opensource-src > UpdateCTestConfiguration from :/home/despre_n/tmp/cmake > space/_build/DartConfiguration.tcl > Parse Config file:/home/despre_n/tmp/cmake > space/_build/DartConfiguration.tcl > Test project /home/despre_n/tmp/cmake space/_build > Constructing a list of tests > Guessing configuration NoConfig > Done constructing a list of tests > Checking test dependency graph... > Checking test dependency graph end > test 89 > Start 89: CPackComponents > > 89: Test command: /home/despre_n/tmp/cmake\ space/_build/bin/ctest > "--build-and-test" "/home/despre_n/tmp/cmake space/Tests/CPackComponents" > "/home/despre_n/tmp/cmake space/_build/Tests/CPackComponents" > "--build-generator" "Unix Makefiles" "--build-project" "CPackComponents" > "--build-makeprogram" "/usr/bin/make" "--build-two-config" "--build-target" > "package" "--build-options" "-DCPACK_BINARY_DEB:BOOL=ON" > "-DCPACK_BINARY_RPM:BOOL=ON" "-DCPACK_BINARY_NSIS:BOOL=ON" > "--graphviz=CPackComponents.dot" "--test-command" "/home/despre_n/tmp/cmake > space/_build/bin/cmake" > "-DCPackComponents_BINARY_DIR:PATH=/home/despre_n/tmp/cmake > space/_build/Tests/CPackComponents" "-P" "/home/despre_n/tmp/cmake > space/Tests/CPackComponents/VerifyResult.cmake" > 89: Test timeout computed to be: 1500 > 89: Generate graphviz: /home/despre_n/tmp/cmake > space/_build/Tests/CPackComponents/CPackComponents.dot > 89: Writing /home/despre_n/tmp/cmake > space/_build/Tests/CPackComponents/CPackComponents.dot.mylib... > 89: Writing /home/despre_n/tmp/cmake > space/_build/Tests/CPackComponents/CPackComponents.dot.mylibapp... > 89: Writing /home/despre_n/tmp/cmake > space/_build/Tests/CPackComponents/CPackComponents.dot.mylib.dependers... > 89: Writing /home/despre_n/tmp/cmake > space/_build/Tests/CPackComponents/CPackComponents.dot.mylibapp.dependers... > 89: Writing /home/despre_n/tmp/cmake > space/_build/Tests/CPackComponents/CPackComponents.dot... > 89: Generate graphviz: /home/despre_n/tmp/cmake > space/_build/Tests/CPackComponents/CPackComponents.dot > 89: Writing /home/despre_n/tmp/cmake > space/_build/Tests/CPackComponents/CPackComponents.dot.mylib... > 89: Writing /home/despre_n/tmp/cmake > space/_build/Tests/CPackComponents/CPackComponents.dot.mylibapp... > 89: Writing /home/despre_n/tmp/cmake > space/_build/Tests/CPackComponents/CPackComponents.dot.mylib.dependers... > 89: Writing /home/despre_n/tmp/cmake > space/_build/Tests/CPackComponents/CPackComponents.dot.mylibapp.dependers... > 89: Writing /home/despre_n/tmp/cmake > space/_build/Tests/CPackComponents/CPackComponents.dot... > 89: Internal cmake changing into directory: /home/despre_n/tmp/cmake > space/_build/Tests/CPackComponents > 89: CMake output == > 89: Configuring > 89: Configuring done > 89: Generating > 89: Generating done > 89: Build files have been written to: /home/despre_n/tmp/cmake > space/_build/Tests/CPackComponents > 89: Configuring > 89: Configuring done > 89: Generating > 89: Generating done > 89: Build files have been written to: /home/despre_n/tmp/cmake > space/_build/Tests/CPackComponents > 89: End CMake output == > 89: Change Dir: /home/despre_n/tmp/cmake space/_build/Tests/CPackComponents > 89: > 89: Run Clean Command:/usr/bin/make "clean" > 89: > 89: Run Build Command:/usr/bin/make "package" > 89: [ 50%] Building CXX object CMakeFiles/mylib.dir/mylib.cpp.o > 89: Linking CXX static library libmylib.a > 89: [ 50%] Built target mylib > 89: [100%] Building CXX object CMakeFiles/mylibapp.dir/mylibapp.cpp.o > 89: Linking CXX executable mylibapp > 89: [100%] Built target mylibapp > 89: Run CPack packaging tool... > 89: CMake Warning (dev) at /home/despre_n/tmp/cmake > space/_build/Tests/CPackComponents/CPackConfig.cmake:54 (SET): > 89: Syntax error in cmake code at > 89: > 89: /home/despre_n/tmp/cmake > space/_build/Tests/CPackComponents/CPackConfig.cmake:54 > 89: > 89: when parsing string > 89: > 89: C:\Program Files\CMake Tests Install Root > 89: > 89: Invalid escape sequence \P > 89: > 89: Policy CMP0010 is not set: Bad variable reference syntax is an error. > Run > 89: "cmake --help-policy CMP0010" for policy details. Use the > cmake_policy > 89: command to set the policy and suppress this warning. > 89: This warning is for project deve
Re: [cmake-developers] find_package module-only policy (was: find_package error wording)
On Sunday 19 February 2012, Brad King wrote: > On 2/18/2012 10:43 AM, Alexander Neundorf wrote: > > This is now in the branch FindPackage_MODULE_MODE_Policy on stage. > > I still have to add tests. > > Thanks for the prototype. I'm not promising acceptance yet > but it is a good reference for discussion. I'm going to > continue the discussion over on Stephen's response in this > thread. > > > I think with this new policy MODULE_MODE should not be considered the > > "simple signature" and NO_MODULE the "full signature" anymore, but both > > with equal rights. > > It used to be one signature but IIRC you asked me to break out the > reduced signature since that is all people need most of the time. > > After thinking about the new _MODE options more I think calling > them just "MODULE" and "CONFIG" is better. Fine with me. 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] find_package error wording
On Sunday, February 19, 2012 16:18:00 Alexander Neundorf wrote: > On Sunday 19 February 2012, Stephen Kelly wrote: > > > The only reason to distribute FindBlub for a CMake-aware project is > > > to wrap up find_package NO_MODULE to produce a nicer message, but > > > that > > > is totally optional. If a project does want to distribute one for > > > reference it should go in the -doc package, not in -dev, and should > > > be > > > put in share/doc/blub or the distro's equivalent. > > > > Good point. > > ...but nobody does it or knows it. Not many KDE developers at least. But KDE developers aren't really known for CMake knowledge anyway. They generally get exposed to as little CMake as possible, so I'm not sure they make a good target usecase. > > However, your suggestion above seems to indicate that that is exactly > > what's being done? > > > > That will make this an error: > > > > cmake_required_version(2.8.8) > > find_package(Qt5Core) > > > > Instead this more noisy version would need to be used: > > > > cmake_required_version(2.8.8) > > find_package(Qt5Core CONFIG_MODE) > > Yes. > And this is good. I disagree :) > Then the error message is "Could not find config file". Above it has to > guess, and the developers will think that FindQt5.cmake is missing. > How should they know that Qt5 ships Qt5Config.cmake files ? feature_summary() should tell them that they have to install the development package for Qt5. Whether they need a Find module or a Config file, they still need to install that, so they might as well do it first. > We always had FindFoo.cmake files for everything, including FindQt4.cmake. > They will not think "oh, probably a Qt5Config.cmake could not be found". > I am 99% sure with this. > > Somebody complained on google+ that cmake is a mess. > If you don't know what to make of an error message, this won't help the > perception. Without knowing what specifically they think is a mess, I don't know. I expect that wasn't part of the + post. Specifics rarely are :) > Just yesterday when I was trying to build parts of kdelibs, and got all the > complaints that neither a Find-module could be found nor a config-file could > be found, I completely didn't know what the right way to fix them is. Is > the Find-module missing, and I should add it, or is the package missing, > because it should have installed a config file. It is usually easy at least with a package manager too see if libfoo-dev is installed. That at least reduces the scope of the error to either CMake not finding the config file (unlikely if a distro package is used, and if you installed it yourself then you might know if you installed it) or requiring a FindFoo.cmake in your CMAKE_MODULE_PATH (and then you have to figure out where it should come from). > I would have to check the sources of each of the missing packages to figure > out whether it installs a config file or not. > > Making this explicit helps. > This will also help in making the Config mode more visible, since it will > not be "hidden" anymore. > You know, people will see > find_package(Qt5 CONFIG_MODE) > and they might have a look what that "CONFIG_MODE" means. > Without it, they won't. Maybe. The current branch isn't my preferred solution. Even after everyone has a firm understanding of what CONFIG_MODE means, we'll still always need it. Maybe another policy in the future would be able to make it the default? I don't know if there's a better solution, but I just wanted to raise my concerns. 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] find_package error wording
On Sunday 19 February 2012, Stephen Kelly wrote: > On Sunday, February 19, 2012 16:18:00 Alexander Neundorf wrote: > > On Sunday 19 February 2012, Stephen Kelly wrote: > > > > The only reason to distribute FindBlub for a CMake-aware project is > > > > to wrap up find_package NO_MODULE to produce a nicer message, but > > > > that > > > > is totally optional. If a project does want to distribute one for > > > > reference it should go in the -doc package, not in -dev, and should > > > > be > > > > put in share/doc/blub or the distro's equivalent. > > > > > > Good point. > > > > ...but nobody does it or knows it. > > Not many KDE developers at least. But KDE developers aren't really known > for CMake knowledge anyway. They generally get exposed to as little CMake > as possible, so I'm not sure they make a good target usecase. Since 6 years KDE developers are my daily target usecase. I think they are the biggest existing group of cmake users out there. I don't think they are very different from other users. Also, what I always tried to do is to hide as little cmake stuff from them as possible. It shouldn't be seen as "magic" what is happening. All the macros etc. I wrote try to be in the same style as the original cmake commands. Look at how boost is using cmake. They are hiding it. Almost completely. I don't like how they use it. Because their users won't have a clue about cmake. > > > However, your suggestion above seems to indicate that that is exactly > > > what's being done? > > > > > > That will make this an error: > > > > > > cmake_required_version(2.8.8) > > > find_package(Qt5Core) > > > > > > Instead this more noisy version would need to be used: > > > > > > cmake_required_version(2.8.8) > > > find_package(Qt5Core CONFIG_MODE) > > > > Yes. > > And this is good. > > I disagree :) > > > Then the error message is "Could not find config file". Above it has to > > guess, and the developers will think that FindQt5.cmake is missing. > > How should they know that Qt5 ships Qt5Config.cmake files ? > > feature_summary() should tell them that they have to install the > development package for Qt5. > > Whether they need a Find module or a Config file, they still need to > install that, so they might as well do it first. Maybe they have already installed it, so they now think a FindQt5.cmake file is missing. It is good to have precise error messages. > > We always had FindFoo.cmake files for everything, including > > FindQt4.cmake. They will not think "oh, probably a Qt5Config.cmake could > > not be found". I am 99% sure with this. > > > > Somebody complained on google+ that cmake is a mess. > > If you don't know what to make of an error message, this won't help the > > perception. > > Without knowing what specifically they think is a mess, I don't know. I > expect that wasn't part of the + post. Specifics rarely are :) > > > Just yesterday when I was trying to build parts of kdelibs, and got all > > the complaints that neither a Find-module could be found nor a config-file > > could be found, I completely didn't know what the right way to fix them > > is. Is the Find-module missing, and I should add it, or is the package > > missing, because it should have installed a config file. > > It is usually easy at least with a package manager too see if libfoo-dev is > installed. > > That at least reduces the scope of the error to either CMake not finding > the config file (unlikely if a distro package is used, and if you See, and with the policy the scope is 100% reduced. Then I know what's wrong. > installed it yourself then you might know if you installed it) or > requiring a > FindFoo.cmake in your CMAKE_MODULE_PATH (and then you have to figure out > where it should come from). > > > I would have to check the sources of each of the missing packages to > > figure out whether it installs a config file or not. > > > > Making this explicit helps. > > This will also help in making the Config mode more visible, since it will > > not be "hidden" anymore. > > You know, people will see > > find_package(Qt5 CONFIG_MODE) > > and they might have a look what that "CONFIG_MODE" means. > > Without it, they won't. > > Maybe. > > The current branch isn't my preferred solution. Even after everyone has a > firm understanding of what CONFIG_MODE means, we'll still always need it. Yes. I don't see a problem with needing an additional keyword. This is what has happened with more or less all cmake commands: in the beginning they had simply a list of arguments, now most of them have two modes, the old one, and a new one which is a bit more verbose and more powerful. Compare find_package(Qt5) vs. find_package(Qt5 CONFIG_MODE) IMO here it's completely "in your face" that "I want a config file". The much better error message is IMO absolutely worth the one extra argument. Now and also in the future. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com
Re: [cmake-developers] CPackComponents fails with spaces in paths
2012/2/19 Eric Noulard > Le 19 février 2012 16:07, Nicolas Desprès a > écrit : > > Hi, > > > > The CPackComponents test fails on master where there is a space in the > > source tree. Here I think the trace: > > > > $ ctest -V -R 'CPackComponents$' > > > > == > > UpdateCTestConfiguration from :/home/despre_n/tmp/cmake > > space/_build/DartConfiguration.tcl > > Parse Config file:/home/despre_n/tmp/cmake > > space/_build/DartConfiguration.tcl > > Add coverage exclude regular expressions. > > Add coverage exclude: XCode > > Add coverage exclude: Kdevelop > > Add coverage exclude: /Source/(cm|kw)sys/ > > Add coverage exclude: /CMakeFiles/CMakeTmp/ > > Add coverage exclude: [A-Za-z]./[Qq]t/qt-.+-opensource-src > > UpdateCTestConfiguration from :/home/despre_n/tmp/cmake > > space/_build/DartConfiguration.tcl > > Parse Config file:/home/despre_n/tmp/cmake > > space/_build/DartConfiguration.tcl > > Test project /home/despre_n/tmp/cmake space/_build > > Constructing a list of tests > > Guessing configuration NoConfig > > Done constructing a list of tests > > Checking test dependency graph... > > Checking test dependency graph end > > test 89 > > Start 89: CPackComponents > > > > 89: Test command: /home/despre_n/tmp/cmake\ space/_build/bin/ctest > > "--build-and-test" "/home/despre_n/tmp/cmake space/Tests/CPackComponents" > > "/home/despre_n/tmp/cmake space/_build/Tests/CPackComponents" > > "--build-generator" "Unix Makefiles" "--build-project" "CPackComponents" > > "--build-makeprogram" "/usr/bin/make" "--build-two-config" > "--build-target" > > "package" "--build-options" "-DCPACK_BINARY_DEB:BOOL=ON" > > "-DCPACK_BINARY_RPM:BOOL=ON" "-DCPACK_BINARY_NSIS:BOOL=ON" > > "--graphviz=CPackComponents.dot" "--test-command" > "/home/despre_n/tmp/cmake > > space/_build/bin/cmake" > > "-DCPackComponents_BINARY_DIR:PATH=/home/despre_n/tmp/cmake > > space/_build/Tests/CPackComponents" "-P" "/home/despre_n/tmp/cmake > > space/Tests/CPackComponents/VerifyResult.cmake" > > 89: Test timeout computed to be: 1500 > > 89: Generate graphviz: /home/despre_n/tmp/cmake > > space/_build/Tests/CPackComponents/CPackComponents.dot > > 89: Writing /home/despre_n/tmp/cmake > > space/_build/Tests/CPackComponents/CPackComponents.dot.mylib... > > 89: Writing /home/despre_n/tmp/cmake > > space/_build/Tests/CPackComponents/CPackComponents.dot.mylibapp... > > 89: Writing /home/despre_n/tmp/cmake > > space/_build/Tests/CPackComponents/CPackComponents.dot.mylib.dependers... > > 89: Writing /home/despre_n/tmp/cmake > > > space/_build/Tests/CPackComponents/CPackComponents.dot.mylibapp.dependers... > > 89: Writing /home/despre_n/tmp/cmake > > space/_build/Tests/CPackComponents/CPackComponents.dot... > > 89: Generate graphviz: /home/despre_n/tmp/cmake > > space/_build/Tests/CPackComponents/CPackComponents.dot > > 89: Writing /home/despre_n/tmp/cmake > > space/_build/Tests/CPackComponents/CPackComponents.dot.mylib... > > 89: Writing /home/despre_n/tmp/cmake > > space/_build/Tests/CPackComponents/CPackComponents.dot.mylibapp... > > 89: Writing /home/despre_n/tmp/cmake > > space/_build/Tests/CPackComponents/CPackComponents.dot.mylib.dependers... > > 89: Writing /home/despre_n/tmp/cmake > > > space/_build/Tests/CPackComponents/CPackComponents.dot.mylibapp.dependers... > > 89: Writing /home/despre_n/tmp/cmake > > space/_build/Tests/CPackComponents/CPackComponents.dot... > > 89: Internal cmake changing into directory: /home/despre_n/tmp/cmake > > space/_build/Tests/CPackComponents > > 89: CMake output == > > 89: Configuring > > 89: Configuring done > > 89: Generating > > 89: Generating done > > 89: Build files have been written to: /home/despre_n/tmp/cmake > > space/_build/Tests/CPackComponents > > 89: Configuring > > 89: Configuring done > > 89: Generating > > 89: Generating done > > 89: Build files have been written to: /home/despre_n/tmp/cmake > > space/_build/Tests/CPackComponents > > 89: End CMake output == > > 89: Change Dir: /home/despre_n/tmp/cmake > space/_build/Tests/CPackComponents > > 89: > > 89: Run Clean Command:/usr/bin/make "clean" > > 89: > > 89: Run Build Command:/usr/bin/make "package" > > 89: [ 50%] Building CXX object CMakeFiles/mylib.dir/mylib.cpp.o > > 89: Linking CXX static library libmylib.a > > 89: [ 50%] Built target mylib > > 89: [100%] Building CXX object CMakeFiles/mylibapp.dir/mylibapp.cpp.o > > 89: Linking CXX executable mylibapp > > 89: [100%] Built target mylibapp > > 89: Run CPack packaging tool... > > 89: CMake Warning (dev) at /home/despre_n/tmp/cmake > > space/_build/Tests/CPackComponents/CPackConfig.cmake:54 (SET): > > 89: Syntax error in cmake code at > > 89: > > 89: /home/despre_n/tmp/cmake > > space/_build/Tests/CPackComponents/CPackConfig.cmake:54 > > 89: > > 89: when parsing string > > 89: > > 89: C:\Program Files\CMake Tests Install Root > > 89: > > 89: Invalid escape sequence \P > > 89: > > 89:
Re: [cmake-developers] CPackComponents fails with spaces in paths
Le 19 février 2012 17:20, Nicolas Desprès a écrit : > > > 2012/2/19 Eric Noulard >> >> Le 19 février 2012 16:07, Nicolas Desprès a >> écrit : >> > Hi, >> > >> > The CPackComponents test fails on master where there is a space in the >> > source tree. Here I think the trace: >> > >> > $ ctest -V -R 'CPackComponents$' >> > >> > == >> > UpdateCTestConfiguration from :/home/despre_n/tmp/cmake >> > space/_build/DartConfiguration.tcl >> > Parse Config file:/home/despre_n/tmp/cmake >> > space/_build/DartConfiguration.tcl >> > Add coverage exclude regular expressions. >> > Add coverage exclude: XCode >> > Add coverage exclude: Kdevelop >> > Add coverage exclude: /Source/(cm|kw)sys/ >> > Add coverage exclude: /CMakeFiles/CMakeTmp/ >> > Add coverage exclude: [A-Za-z]./[Qq]t/qt-.+-opensource-src >> > UpdateCTestConfiguration from :/home/despre_n/tmp/cmake >> > space/_build/DartConfiguration.tcl >> > Parse Config file:/home/despre_n/tmp/cmake >> > space/_build/DartConfiguration.tcl >> > Test project /home/despre_n/tmp/cmake space/_build >> > Constructing a list of tests >> > Guessing configuration NoConfig >> > Done constructing a list of tests >> > Checking test dependency graph... >> > Checking test dependency graph end >> > test 89 >> > Start 89: CPackComponents >> > >> > 89: Test command: /home/despre_n/tmp/cmake\ space/_build/bin/ctest >> > "--build-and-test" "/home/despre_n/tmp/cmake >> > space/Tests/CPackComponents" >> > "/home/despre_n/tmp/cmake space/_build/Tests/CPackComponents" >> > "--build-generator" "Unix Makefiles" "--build-project" "CPackComponents" >> > "--build-makeprogram" "/usr/bin/make" "--build-two-config" >> > "--build-target" >> > "package" "--build-options" "-DCPACK_BINARY_DEB:BOOL=ON" >> > "-DCPACK_BINARY_RPM:BOOL=ON" "-DCPACK_BINARY_NSIS:BOOL=ON" >> > "--graphviz=CPackComponents.dot" "--test-command" >> > "/home/despre_n/tmp/cmake >> > space/_build/bin/cmake" >> > "-DCPackComponents_BINARY_DIR:PATH=/home/despre_n/tmp/cmake >> > space/_build/Tests/CPackComponents" "-P" "/home/despre_n/tmp/cmake >> > space/Tests/CPackComponents/VerifyResult.cmake" >> > 89: Test timeout computed to be: 1500 >> > 89: Generate graphviz: /home/despre_n/tmp/cmake >> > space/_build/Tests/CPackComponents/CPackComponents.dot >> > 89: Writing /home/despre_n/tmp/cmake >> > space/_build/Tests/CPackComponents/CPackComponents.dot.mylib... >> > 89: Writing /home/despre_n/tmp/cmake >> > space/_build/Tests/CPackComponents/CPackComponents.dot.mylibapp... >> > 89: Writing /home/despre_n/tmp/cmake >> > >> > space/_build/Tests/CPackComponents/CPackComponents.dot.mylib.dependers... >> > 89: Writing /home/despre_n/tmp/cmake >> > >> > space/_build/Tests/CPackComponents/CPackComponents.dot.mylibapp.dependers... >> > 89: Writing /home/despre_n/tmp/cmake >> > space/_build/Tests/CPackComponents/CPackComponents.dot... >> > 89: Generate graphviz: /home/despre_n/tmp/cmake >> > space/_build/Tests/CPackComponents/CPackComponents.dot >> > 89: Writing /home/despre_n/tmp/cmake >> > space/_build/Tests/CPackComponents/CPackComponents.dot.mylib... >> > 89: Writing /home/despre_n/tmp/cmake >> > space/_build/Tests/CPackComponents/CPackComponents.dot.mylibapp... >> > 89: Writing /home/despre_n/tmp/cmake >> > >> > space/_build/Tests/CPackComponents/CPackComponents.dot.mylib.dependers... >> > 89: Writing /home/despre_n/tmp/cmake >> > >> > space/_build/Tests/CPackComponents/CPackComponents.dot.mylibapp.dependers... >> > 89: Writing /home/despre_n/tmp/cmake >> > space/_build/Tests/CPackComponents/CPackComponents.dot... >> > 89: Internal cmake changing into directory: /home/despre_n/tmp/cmake >> > space/_build/Tests/CPackComponents >> > 89: CMake output == >> > 89: Configuring >> > 89: Configuring done >> > 89: Generating >> > 89: Generating done >> > 89: Build files have been written to: /home/despre_n/tmp/cmake >> > space/_build/Tests/CPackComponents >> > 89: Configuring >> > 89: Configuring done >> > 89: Generating >> > 89: Generating done >> > 89: Build files have been written to: /home/despre_n/tmp/cmake >> > space/_build/Tests/CPackComponents >> > 89: End CMake output == >> > 89: Change Dir: /home/despre_n/tmp/cmake >> > space/_build/Tests/CPackComponents >> > 89: >> > 89: Run Clean Command:/usr/bin/make "clean" >> > 89: >> > 89: Run Build Command:/usr/bin/make "package" >> > 89: [ 50%] Building CXX object CMakeFiles/mylib.dir/mylib.cpp.o >> > 89: Linking CXX static library libmylib.a >> > 89: [ 50%] Built target mylib >> > 89: [100%] Building CXX object CMakeFiles/mylibapp.dir/mylibapp.cpp.o >> > 89: Linking CXX executable mylibapp >> > 89: [100%] Built target mylibapp >> > 89: Run CPack packaging tool... >> > 89: CMake Warning (dev) at /home/despre_n/tmp/cmake >> > space/_build/Tests/CPackComponents/CPackConfig.cmake:54 (SET): >> > 89: Syntax error in cmake code at >> > 89: >> > 89: /home/despre_n/tmp/cmake >> > space/_build/Tests/CPac
Re: [cmake-developers] Making GUI applications by default
Brad King wrote: > On 2/17/2012 9:27 AM, Stephen Kelly wrote: >>> Then add SetPropertyDefault in the initialization of EXECUTABLE targets >>> so that >>> >>> set(CMAKE_GUI_EXECUTABLE 1) >>> >>> will change the default for new executable targets in scope of the >>> variable. >> >> Yes, I had the same idea last night after emailing. >> >> I can implement that. > > Great. On second thought I wonder if a better name for the property > is "EXECUTABLE_GUI" since that uses the prefix "EXECUTABLE_" which > can be re-used later for other properties that are specific to > executable targets. Then one could write > >set(CMAKE_EXECUTABLE_GUI 1) > > for the variable version and "CMAKE_EXECUTABLE_" is the prefix for > settings related to executables. > I've implemented this in my gitorious clone: https://gitorious.org/~steveire/cmake/steveires- cmake/commits/executable_gui-property I am not sure whether you want getting the EXECUTABLE_GUI property to work for the cross-platform abstraction too. For now that is two commits. I can remove or squash the second commit depending on what you prefer. Let me know if I can merge to next. 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] CPackComponents fails with spaces in paths
2012/2/19 Eric Noulard > Le 19 février 2012 17:20, Nicolas Desprès a > écrit : > > > > > > 2012/2/19 Eric Noulard > >> > >> Le 19 février 2012 16:07, Nicolas Desprès a > >> écrit : > >> > Hi, > >> > > >> > The CPackComponents test fails on master where there is a space in the > >> > source tree. Here I think the trace: > >> > > >> > $ ctest -V -R 'CPackComponents$' > >> > > >> > == > >> > UpdateCTestConfiguration from :/home/despre_n/tmp/cmake > >> > space/_build/DartConfiguration.tcl > >> > Parse Config file:/home/despre_n/tmp/cmake > >> > space/_build/DartConfiguration.tcl > >> > Add coverage exclude regular expressions. > >> > Add coverage exclude: XCode > >> > Add coverage exclude: Kdevelop > >> > Add coverage exclude: /Source/(cm|kw)sys/ > >> > Add coverage exclude: /CMakeFiles/CMakeTmp/ > >> > Add coverage exclude: [A-Za-z]./[Qq]t/qt-.+-opensource-src > >> > UpdateCTestConfiguration from :/home/despre_n/tmp/cmake > >> > space/_build/DartConfiguration.tcl > >> > Parse Config file:/home/despre_n/tmp/cmake > >> > space/_build/DartConfiguration.tcl > >> > Test project /home/despre_n/tmp/cmake space/_build > >> > Constructing a list of tests > >> > Guessing configuration NoConfig > >> > Done constructing a list of tests > >> > Checking test dependency graph... > >> > Checking test dependency graph end > >> > test 89 > >> > Start 89: CPackComponents > >> > > >> > 89: Test command: /home/despre_n/tmp/cmake\ space/_build/bin/ctest > >> > "--build-and-test" "/home/despre_n/tmp/cmake > >> > space/Tests/CPackComponents" > >> > "/home/despre_n/tmp/cmake space/_build/Tests/CPackComponents" > >> > "--build-generator" "Unix Makefiles" "--build-project" > "CPackComponents" > >> > "--build-makeprogram" "/usr/bin/make" "--build-two-config" > >> > "--build-target" > >> > "package" "--build-options" "-DCPACK_BINARY_DEB:BOOL=ON" > >> > "-DCPACK_BINARY_RPM:BOOL=ON" "-DCPACK_BINARY_NSIS:BOOL=ON" > >> > "--graphviz=CPackComponents.dot" "--test-command" > >> > "/home/despre_n/tmp/cmake > >> > space/_build/bin/cmake" > >> > "-DCPackComponents_BINARY_DIR:PATH=/home/despre_n/tmp/cmake > >> > space/_build/Tests/CPackComponents" "-P" "/home/despre_n/tmp/cmake > >> > space/Tests/CPackComponents/VerifyResult.cmake" > >> > 89: Test timeout computed to be: 1500 > >> > 89: Generate graphviz: /home/despre_n/tmp/cmake > >> > space/_build/Tests/CPackComponents/CPackComponents.dot > >> > 89: Writing /home/despre_n/tmp/cmake > >> > space/_build/Tests/CPackComponents/CPackComponents.dot.mylib... > >> > 89: Writing /home/despre_n/tmp/cmake > >> > space/_build/Tests/CPackComponents/CPackComponents.dot.mylibapp... > >> > 89: Writing /home/despre_n/tmp/cmake > >> > > >> > > space/_build/Tests/CPackComponents/CPackComponents.dot.mylib.dependers... > >> > 89: Writing /home/despre_n/tmp/cmake > >> > > >> > > space/_build/Tests/CPackComponents/CPackComponents.dot.mylibapp.dependers... > >> > 89: Writing /home/despre_n/tmp/cmake > >> > space/_build/Tests/CPackComponents/CPackComponents.dot... > >> > 89: Generate graphviz: /home/despre_n/tmp/cmake > >> > space/_build/Tests/CPackComponents/CPackComponents.dot > >> > 89: Writing /home/despre_n/tmp/cmake > >> > space/_build/Tests/CPackComponents/CPackComponents.dot.mylib... > >> > 89: Writing /home/despre_n/tmp/cmake > >> > space/_build/Tests/CPackComponents/CPackComponents.dot.mylibapp... > >> > 89: Writing /home/despre_n/tmp/cmake > >> > > >> > > space/_build/Tests/CPackComponents/CPackComponents.dot.mylib.dependers... > >> > 89: Writing /home/despre_n/tmp/cmake > >> > > >> > > space/_build/Tests/CPackComponents/CPackComponents.dot.mylibapp.dependers... > >> > 89: Writing /home/despre_n/tmp/cmake > >> > space/_build/Tests/CPackComponents/CPackComponents.dot... > >> > 89: Internal cmake changing into directory: /home/despre_n/tmp/cmake > >> > space/_build/Tests/CPackComponents > >> > 89: CMake output == > >> > 89: Configuring > >> > 89: Configuring done > >> > 89: Generating > >> > 89: Generating done > >> > 89: Build files have been written to: /home/despre_n/tmp/cmake > >> > space/_build/Tests/CPackComponents > >> > 89: Configuring > >> > 89: Configuring done > >> > 89: Generating > >> > 89: Generating done > >> > 89: Build files have been written to: /home/despre_n/tmp/cmake > >> > space/_build/Tests/CPackComponents > >> > 89: End CMake output == > >> > 89: Change Dir: /home/despre_n/tmp/cmake > >> > space/_build/Tests/CPackComponents > >> > 89: > >> > 89: Run Clean Command:/usr/bin/make "clean" > >> > 89: > >> > 89: Run Build Command:/usr/bin/make "package" > >> > 89: [ 50%] Building CXX object CMakeFiles/mylib.dir/mylib.cpp.o > >> > 89: Linking CXX static library libmylib.a > >> > 89: [ 50%] Built target mylib > >> > 89: [100%] Building CXX object CMakeFiles/mylibapp.dir/mylibapp.cpp.o > >> > 89: Linking CXX executable mylibapp > >> > 89: [100%] Built target mylibapp > >> > 89: Run CPack
Re: [cmake-developers] Modifying RPATH feature to run tests uninstalled
Brad King wrote: > On 2/17/2012 9:13 AM, Stephen Kelly wrote: >> If CMAKE_SKIP_INSTALL_RPATH is used by our buildsystems and >> CMAKE_SKIP_RPATH is not, distros will learn that they can run unit tests >> if they build their packages with the former instead of the latter. >> >> From my point of view though, the ENVIRONMENT property manipulation >> solves >> enough of the problem already. It makes 'make test' work. >> >> What it doesn't fix is running a unit test executable directly without >> setting the environment manually or running make install. I don't see why >> that should be expected to work though if the developer disables the >> RPATH stuff. It also doesn't work currently (without wrapper scripts), so >> nothing is really lost. >> >> However, adding CMAKE_SKIP_INSTALL_RPATH would make that work even if a >> developer wanted to disable RPATH, so maybe it's a nice thing to do. > > This is achievable by project code if it never sets INSTALL_RPATH. > However it can be convenient for distros to have a "hammer" like > CMAKE_SKIP_INSTALL_RPATH to avoid patching uncooperative projects. > > Distros are using CMAKE_SKIP_RPATH as that hammer now, and it's a > pain for tests. I think CMAKE_SKIP_INSTALL_RPATH is the right > balance. It allows tests to run and distros to avoid RPATH in > their packages. I have also added a skip-install-rpath branch to my clone for review. So far it's a quick hack. I'm not sure if I'm barking up the right or wrong tree. 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 generator on Windows
Peter Collingbourne writes: [snip] > I found that on Windows (on my machine at least), some try_compile > runs were non-deterministic, and this caused build failures in CMake. > I also encountered the issue Oscar mentioned in the other thread > regarding the pdb file being locked (maybe the two issues are > related). It was Peter Kümmel who mentioned the problem about locked files (and there was no mention of pdb files) but I'm interested anyways. Can you describe the problem? Long time ago there was a locking problem with pdb files on Clang when doing top-level parallel builds (something only a few VS do). It consisted on having an .exe and a .dll with the same name (clang.exe and clang.dll). When clang.exe was created, clang.pdb was created as well. But clang.dll generates clang.pdb too... Basically, the build was broken due to a name collision. Even when the build did not stop due to clang.pdb being locked, it was wrong anyways because we were overwriting the debug file of either clang.exe or clang.dll. So we decided to rename clang.dll to libclang.dll. > But I was able to successfully compile most of LLVM/Clang on Windows. Where did it failed? -- 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
