Re: [cmake-developers] organizing "concept" documentation (was: RST and documentation)
Brad King wrote: >> * cmake_minumum_required/policies > > This can go in the introduction of the cmake-policies.7 manual page > and be linked from the cmake_minumum_required command. Done, but can be expanded more I suppose. >> * project/languages >> * cross-compiling/toolchain files etc. > > How about a "cmake-toolchains.7" manual for these two? Sounds good to me. >> * find_package/Find modules/Config modules >> * imported and other pseudo/special targets, and exporting them > > Create a "cmake-packages.7" manual that covers these. Ok. I think I'll put the exporting targets section in the below manual though. >> * build targets, various library types, target properties like PIC etc >> * usage requirements > > I think these all belong in a dedicated manual but I can't think of > a good name off the top of my head right now. * cmake-targets.7 * cmake-buildsystem.7 <-- My preference. * cmake-listsfiles.7 * cmake-outputs.7 Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake --help-custom-modules compatibility
Brad King wrote: > On 11/18/2013 04:34 PM, Alexander Neundorf wrote: >> the author of the --help-custom-modules command line option certainly >> intended this to be used by other projects. ;-) >> I don't know whether this is used only in KDE or also in other projects. > > The solution is still to re-implement the "--help-custom-modules myman.1" > command-line behavior as a special case with warnings. Alex and Steve > will have to work out who takes responsibility for that. I'll defer to Alex on doing that I think. As an unrelated matter, I would like to find out whether any packages in, eg debian fail to build with CMake 3. I'll try to figure out a way to find out. --unknownUnknowns; Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake --help output indentation (was: RST and documentation)
Brad King wrote: > IMO the --help-* command-line options are > still present only for basic compatibility with pre-3.0 help and > should not be a focus of workflow enhancements. I don't consider --help-command an 'only compatibility' feature. It's the primary way I read cmake documentation. > The output of the > individual domain objects is still pretty easy to use. By 'domain object', do you mean the individual .rst files? How would you read them without --help-command and without find+cat? How find+cat easier than --help-command? > All the > other output is just whole man pages which are better viewed with > real man page or html viewers. The --help-command option is much more convenient than man cmake-commands /find_package n # enough times to get to the find_package docs, not references to it. It is also a disadvantage that the man context is not the command line context. Think of when you use cat or head instead of vi/less. Are you referring to something more convenient? I'm not a man page expert. There may be another way to get to the find_package docs than the above? 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] Using tags in Mantis
Hi, I was wondering what folks thought of going through the bug tracker and attaching tags to bugs to help bubble some up to the top. Some tags are used, but it doesn't seem all that consistent in usage or style. To start with, how about tags such as: cmake-patch - Patch attached to the bug (or diff in the comments). cmake-ezfix - Easy fixes for new contributors. cmake-need-policy - Bugs which need a policy to be fixed properly. cmake-rfe - Feature requests. cmake-gen-$generator - Generator-related bugs (ninja, make, eclipse, vs$year, xcode, etc.). cmake-platform-$platform - Platform-specific bugs (Windows, OSX, Linux, etc.). cmake-compiler-$compiler - Compiler-specific bugs (xlc, gcc, clang, etc.). cmake-lang-$lang - Language-specific bugs (c, cxx, java, etc.) cmake-policy-$policy - Policy-related bugs. cmake-find-pkg-$package - FindXXX.cmake-related bugs. cmake-pony - Bugs wishing for CMake to help ponies fly. The 'cmake-' prefix is because the bug tracker is also used for other projects. This would also probably be a good time to close bugs which got skipped over (I found one of mine which was fixed, but that never got back to mantis). Any other tags which would be useful (maybe not cmake-pony...)? How much would tags be used? Would they be helpful? --Ben -- 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] FindBacktrace.cmake
2013/11/19 Vadim Zhukov : > 2013/11/19 Brad King : >> On 07/31/2013 10:06 AM, Brad King wrote: >>> The dependency is now in master so please rebase find_backtrace >>> on that so you can use the reset feature. >> >> The find_backtrace topic has not yet been merged to 'next' for >> testing. After the documentation transition I rebased and revised >> the topic once to use the new documentation system but otherwise >> did not change it. >> >> Has this topic been updated to use the reset feature of >> CMakePushCheckState? Please check/revise the current topic on >> the stage and merge to 'next' for testing or remove it if you no >> longer wish to contribute this module. > > Sorry for slacking. I've mishandled the topic repo on my side with > erroneous "git rebase", then was forced to do other things and kept it > unupdated for a long time. I'll revise and update the topic today or > tomorrow. Thank you for reminding and sorry again. I've pushed the version which uses cmake_push_check_state(RESET). -- WBR, Vadim Zhukov -- 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 0014587]: Add support for wxWidgets 3.0.0
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14587 == Reported By:adesmier_fr Assigned To: == Project:CMake Issue ID: 14587 Category: CMake Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2013-11-20 10:05 EST Last Modified: 2013-11-20 10:05 EST == Summary:Add support for wxWidgets 3.0.0 Description: Currently cmake can not find wxWidgets 3.0.0. Find attached patch that solve this issue == Issue History Date ModifiedUsername FieldChange == 2013-11-20 10:05 adesmier_frNew Issue 2013-11-20 10:05 adesmier_frFile Added: FindwxWidgets.cmake.diff == -- 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] file(DOWNLOAD) + EXPECTED_HASH security issue
On 11/20/2013 04:05 AM, Daniele E. Domenichelli wrote: >> The "this->SetError/return false" logic for these errors should be >> replaced by "this->IssueMessage(cmake::FATAL_ERROR,...)/return true" >> to switch it to a fatal error. The signature should be extended >> to provide an option to get the error information back without >> causing a CMake Error so that the caller can handle it. > > What about setting the STATUS variable to > "some number different from 0; check failed" instead? > In this way the default behaviour won't change and there is no need to > extend the signature, but if you check the STATUS variable, you will be > able to issue a fatal error. > Also if download fails in some other way, the error raised is not fatal, > therefore in this way it looks more coherent. Once a command reports an error CMake will not generate the project so it is not worth allowing the configuration to do much after that. Failure of file(DOWNLOAD) should either be a cmake::FATAL_ERROR or just a STATUS setting with no CMake Error. The signature needs a way for CMake to know which one to do. I'm fine with changing the current non-fatal error to a fatal error in the next release. -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 0014586]: LLVM platform toolset for Visual Studio
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=14586 == Reported By:Daniel Pfeifer Assigned To: == Project:CMake Issue ID: 14586 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2013-11-20 06:19 EST Last Modified: 2013-11-20 06:19 EST == Summary:LLVM platform toolset for Visual Studio Description: When configuring a CMake project with an LLVM toolset, CMake complains about the compiler not being able to compile a simpe test program. The complete output is attached. It seems the problem is the '-g' compile flag. Steps to Reproduce: * Install Visual Studio * Install LLVM from http://llvm.org/builds/ * `cmake -G "Visual Studio 12" -T "LLVM-vs2013"` == Issue History Date ModifiedUsername FieldChange == 2013-11-20 06:19 Daniel Pfeifer New Issue 2013-11-20 06:19 Daniel Pfeifer File Added: output.txt == -- 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] New CPack WiX Generator Component Support
I've staged a new topic "wix-components" that adds basic component support to the CPack WiX generator: http://cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/wix-components I would like to encourage anyone interested in this to inspect and/or try out the changes and provide feedback. Would anyone be unhappy if I would postpone support for component inter-dependencies? I haven't yet found a proper way to handle these in WiX. Nils -- 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] Silent failure of attaching custom commands to non existing target
On 19.11.2013 18:34, Brad King wrote: We would need a policy because existing project releases inevitably contain such code by accident need to continue to work, albeit with a policy warning. I created a topic "missing-target-error" for this but it currently conflicts with "constify" in Source/cmMakefile.cxx. Nils -- 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] file(DOWNLOAD) + EXPECTED_HASH security issue
On 19/11/13 16:34, Brad King wrote: >> * The "STATUS" variable is not set, therefore it is not useful; >> * The "faulty" downloaded file is not removed. >> >> So I believe that there is no way to stop CMake, unless you perform >> another hash check. > > The "this->SetError/return false" logic for these errors should be > replaced by "this->IssueMessage(cmake::FATAL_ERROR,...)/return true" > to switch it to a fatal error. The signature should be extended > to provide an option to get the error information back without > causing a CMake Error so that the caller can handle it. What about setting the STATUS variable to "some number different from 0; check failed" instead? In this way the default behaviour won't change and there is no need to extend the signature, but if you check the STATUS variable, you will be able to issue a fatal error. Also if download fails in some other way, the error raised is not fatal, therefore in this way it looks more coherent. Daniele -- 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
