Re: [cmake-developers] [Patch 3/5] Improved WIX support
> -Original Message- > From: Nils Gladitz [mailto:nilsglad...@gmail.com] > Sent: Tuesday, August 02, 2016 10:47 AM > To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers > Subject: Re: [cmake-developers] [Patch 3/5] Improved WIX support > > On 07/20/2016 03:58 PM, Stuermer, Michael SP/HZA-ZSEP wrote: > > > Using the patchfile support I managed to implement the service installation > issue I had, so the unnecessary features from the last patch are removed > now. > > > > I tested all patches separately and hope they work now. > > > > looking forward for feedback, > > > > best regrads, > > Michael > > Patch 3 looks OK but I think I would prefer using WiX over CPack > nomenclature in the variables you introduce. > > e.g. > > CPACK_WIX_ROOT_FEATURE_TITLE and > CPACK_WIX_ROOT_FEATURE_DESCRIPTION > > over > > CPACK_WIX_ROOT_COMPONENT_DISPLAY_NAME and > CPACK_WIX_ROOT_COMPONENT_DESCRIPTION > > given that CPack has no concept of a root component. > > Would you agree? > totally. > Nils Best Regards Michael Stürmer -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [Patch 3/5] Improved WIX support
On 08/02/2016 01:29 PM, Stuermer, Michael SP/HZA-ZSEP wrote: -Original Message- From: Nils Gladitz [mailto:nilsglad...@gmail.com] Sent: Tuesday, August 02, 2016 10:47 AM To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers Subject: Re: [cmake-developers] [Patch 3/5] Improved WIX support Patch 3 looks OK but I think I would prefer using WiX over CPack nomenclature in the variables you introduce. e.g. CPACK_WIX_ROOT_FEATURE_TITLE and CPACK_WIX_ROOT_FEATURE_DESCRIPTION over CPACK_WIX_ROOT_COMPONENT_DISPLAY_NAME and CPACK_WIX_ROOT_COMPONENT_DESCRIPTION given that CPack has no concept of a root component. Would you agree? totally. Thanks. I added a release note, modified the commit message and merged to "next" for testing: https://cmake.org/gitweb?p=cmake.git;a=commit;h=e29bfbf2 Nils -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Let CMake know that clang uses the GCC toolchain.
> In the gcc-like variant the CMAKE_{C,CXX}_SIMULATE_ID > should be detected as GNU and cause the existing code to work. Huh, it doesn't look like that variable is set automatically when using clang with the gcc toolchain. Is that supposed to happen? It should be set manually (say, in a toolchain file)? On Tue, Aug 2, 2016 at 10:08 AM, Brad Kingwrote: > On 07/29/2016 05:44 PM, Chaoren Lin via cmake-developers wrote: > > Clang on Windows uses the GCC toolchain, so we need to avoid using > > backslashes for paths in response files. > [snip] > >strcmp(mf->GetSafeDefinition("CMAKE_C_COMPILER_ID"), "GNU") == 0 > || > >strcmp(mf->GetSafeDefinition("CMAKE_CXX_COMPILER_ID"), "GNU") == > 0 || > >strcmp(mf->GetSafeDefinition("CMAKE_C_SIMULATE_ID"), "GNU") == 0 > || > > - strcmp(mf->GetSafeDefinition("CMAKE_CXX_SIMULATE_ID"), "GNU") == > 0) { > > Clang on Windows also comes in a cl-like variant whose response files may > need backslashes. In the gcc-like variant the CMAKE_{C,CXX}_SIMULATE_ID > should be detected as GNU and cause the existing code to work. What goes > wrong in your use case? > > Thanks, > -Brad > > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Allow custom osx framework locations.
On 07/30/2016 10:48 AM, David Keller wrote: > This allows non-standard locations to be searched, e.g. brew, port. Thanks, applied: CMakeFindFrameworks: Allow custom framework locations https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9970cdcb FYI, this module really only exists for legacy reasons. The find_* commands know how to search frameworks already, and support some variables that can be set to add more search locations. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] FindProtobuf backward compatibility issue for PROTOBUF_IMPORT_DIRS
On 07/29/2016 11:10 PM, Konstantin Sinitsyn wrote: > After recent changes in FindProtobuf.cmake protobuf_generate_cpp > doesn't take into account PROTOBUF_IMPORT_DIRS (in upper case) anymore. [snip] > Here's the patch to fix this: Thanks, applied: FindProtobuf: Restore support for PROTOBUF_IMPORT_DIRS https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5790d9b6 I've queued this for merge to 'release' for 3.6.2. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] QtAutogen 3.6.0 directory nesting overflow patch
On 07/31/2016 03:56 PM, Sebastian Holtermann wrote: >> I have updated the patch for CMake 3.6.0 to fix >> https://gitlab.kitware.com/cmake/cmake/issues/16209 > Here is an updated patch. Thanks. However, it is too late to restore this change for the 3.6 series. 3.6.1 reverted the change. We can re-introduce it for 3.7 so that it can go through another round of release candidates. Please rebase on `master` and include all needed changes as if this change were being made for the first time, including the restoration of the tests. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Use full path for all source files in ninja build.
On 08/02/2016 01:08 PM, Brad King wrote: > Ninja: Use full path for all source files > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d867f8a0 I had to revert that because it causes the Qt*Autogen tests to fail. Also it may break builds on Windows. There are multiple problems: * ConvertToNinjaPath does more than just relative path conversions. It also converts slashes on Windows. Furthermore, it deals with CMAKE_NINJA_OUTPUT_PATH_PREFIX, though that won't matter for absolute paths. * Calls to AddAssumedSourceDependencies and HasCustomCommandOutput later in cmNinjaTargetGenerator::WriteObjectBuildStatement expect to be given paths that come out of ConvertToNinjaPath. * Ninja does not seem to be able to reconcile a dependency on an absolute path with a build statement providing that path by relative path. Custom commands that generate source files list their outputs with ConvertToNinjaPath. Basically everything assumes that all paths written as inputs or outputs of Ninja build statements have gone through the ConvertToNinjaPath method. The special case for "RC" in the existing code is likely buggy. Ninja always uses the location of the build.ninja file as the current working directory, so an IDE that sees a relative path in an error message can interpret it relative to that. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] "Run ranlib on archives only if the tool is available" not in 3.6.1 release
On 07/22/2016 04:24 PM, Ryan D Retting wrote: > I've been waiting for the following commit to get included in an official > release. I just checked today's 3.6.1 and it's still not there. 3.6.1 is a patch release. Only documentation updates and fixes for regressions from 3.5 are eligible for patch releases. The fix you linked was made in post-3.6 development and will be included in 3.7. Meanwhile the nightly binaries or a build from source can be used. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH v3 6/7] Use Windows version of Directory::Load for MinGW too
On 07/20/2016 10:27 AM, Brad King wrote: > On 07/06/2016 03:12 PM, Dāvis Mosāns wrote: >> Otherwise it would use POSIX functions which works only for ASCII paths. > > Thanks. Applied to KWSys first with minor tweaks: > > http://review.source.kitware.com/21349 After being rewritten by another contributor there the change is now in KWSys master. I've updated CMake's copy to get it: KWSys 2016-08-01 (560bcdbb) https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6bc3073e -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Let CMake know that clang uses the GCC toolchain.
On 07/29/2016 05:44 PM, Chaoren Lin via cmake-developers wrote: > Clang on Windows uses the GCC toolchain, so we need to avoid using > backslashes for paths in response files. [snip] >strcmp(mf->GetSafeDefinition("CMAKE_C_COMPILER_ID"), "GNU") == 0 || >strcmp(mf->GetSafeDefinition("CMAKE_CXX_COMPILER_ID"), "GNU") == 0 || >strcmp(mf->GetSafeDefinition("CMAKE_C_SIMULATE_ID"), "GNU") == 0 || > - strcmp(mf->GetSafeDefinition("CMAKE_CXX_SIMULATE_ID"), "GNU") == 0) { Clang on Windows also comes in a cl-like variant whose response files may need backslashes. In the gcc-like variant the CMAKE_{C,CXX}_SIMULATE_ID should be detected as GNU and cause the existing code to work. What goes wrong in your use case? Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Use full path for all source files in ninja build.
On 07/29/2016 05:44 PM, Chaoren Lin via cmake-developers wrote: > From: Chaoren Lin> > Relative paths are difficult for an IDE to parse the output of > a build error. Thanks, applied: Ninja: Use full path for all source files https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d867f8a0 This is more consistent with the Makefile generator behavior too. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH v4 4/4] For Windows encode process output to internally used encoding
On 07/21/2016 08:43 PM, Dāvis Mosāns wrote: > With MultiByteToWideChar such partial char would be replaced with ? (U+003F) > or � (U+FFFD). [snip] > Also could check if last character is ? and try again with one byte less. This may be a good middle ground. The excess bytes would then be buffered for inclusion at the beginning of the next block conversion. How are we to know the encoding being produced by the child? > from WaitForData we're getting data and length, and I assume that data > might not be null-terminated but kwsysEncoding_mbstowcs expects source to be > null-terminated and doesn't accept length. Okay, thanks. Using MultiByteToWideChar for Windows-specific code is fine. If we ever need to offer a similar generalization then we can provide a kwsysEncoding_mbsnrtowcs later. BTW, with all your changes to KWSys it may be easier to iterate if you contribute to KWSys directly. Please see instructions here: http://public.kitware.com/Wiki/KWSys/Git/Develop Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Use full path for all source files in ninja build.
On 08/02/2016 02:11 PM, Chaoren Lin wrote: > Would changing ConvertToNinjaPath to output absolute paths paths work? No, that will make all paths absolute. Ninja's design is pretty clear in that it prefers canonical relative paths when possible. Note that the conversion to a relative path by ConvertToNinjaPath is not unconditional. In an out-of-source build the paths to the source files in the source tree will be absolute. --- Compilers know the absolute path to all the files in a translation unit since the preprocessor was able to read them. They could be taught to produce absolute paths in their error messages to work better for IDEs regardless of how the build system invokes them. I've never really understood why they don't make error messages and debug info hold absolute paths. For some reason relative paths in these places are always blamed on the build system when in fact the compiler could easily produce them. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake -E capabilities [attempt 2]
On 07/29/2016 06:01 AM, Tobias Hunger wrote: > I pushed an update that takes most of the feedback into account. Thanks. I've applied the extra generator refactoring parts first: Refactor extra generator registration to use factories https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bc44627b Report more information about extra generators in generator factories https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=034caa27 Once that tests cleanly I'll merge it to `master` and then we can rebase the remaining changes on it. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Use full path for all source files in ninja build.
On Tue, Aug 02, 2016 at 11:11:44 -0700, Chaoren Lin via cmake-developers wrote: > Similarly, the :make command in vim will have no knowledge of build.gradle, > and only tries to parse the build errors directly. FWIW, I haven't encountered any problems with Vim's :make with CMake's generated Ninja files in out-of-source builds for in-source or generated files (I almost never do in-source builds). --Ben -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Use full path for all source files in ninja build.
> Ninja always uses the location of the build.ninja file as > the current working directory, so an IDE that sees a relative > path in an error message can interpret it relative to that. Our IDE has no knowledge of the build.gradle file let alone where it is located, it just sees the build output and tries to located the mentioned files. Similarly, the :make command in vim will have no knowledge of build.gradle, and only tries to parse the build errors directly. Would changing ConvertToNinjaPath to output absolute paths paths work? On Tue, Aug 2, 2016 at 10:38 AM, Brad Kingwrote: > On 08/02/2016 01:08 PM, Brad King wrote: > > Ninja: Use full path for all source files > > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d867f8a0 > > I had to revert that because it causes the Qt*Autogen tests to > fail. Also it may break builds on Windows. > > There are multiple problems: > > * ConvertToNinjaPath does more than just relative path conversions. > It also converts slashes on Windows. Furthermore, it deals with > CMAKE_NINJA_OUTPUT_PATH_PREFIX, though that won't matter for > absolute paths. > > * Calls to AddAssumedSourceDependencies and HasCustomCommandOutput > later in cmNinjaTargetGenerator::WriteObjectBuildStatement expect > to be given paths that come out of ConvertToNinjaPath. > > * Ninja does not seem to be able to reconcile a dependency on > an absolute path with a build statement providing that path > by relative path. Custom commands that generate source files > list their outputs with ConvertToNinjaPath. > > Basically everything assumes that all paths written as inputs > or outputs of Ninja build statements have gone through the > ConvertToNinjaPath method. The special case for "RC" in the > existing code is likely buggy. > > Ninja always uses the location of the build.ninja file as > the current working directory, so an IDE that sees a relative > path in an error message can interpret it relative to that. > > -Brad > > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [ISSUE] Bump to 3.2 and continue...
29.07.2016, 23:56, "Konstantin Podsvirov": > Hello CMake developers, > > I found bug: > > https://gitlab.kitware.com/cmake/cmake/issues/16220 > > I found it, but I do not want to deal with it ... Okay, I have solution. May be attached patch will be more useful then MR (https://gitlab.kitware.com/cmake/cmake/merge_requests/51). > -- > Regards, > Konstantin Podsvirov > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers Regards, Konstantin Podsvirov From c9d3fada704ffe40b996b0e8b33e0ba3935c7b01 Mon Sep 17 00:00:00 2001 From: Konstantin Podsvirov Date: Mon, 1 Aug 2016 23:16:55 +0300 Subject: [PATCH] Remove using of continue() method It's needed for backward compatible with CMake 2.8.4. --- Utilities/Sphinx/CMakeLists.txt | 19 +++ 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/Utilities/Sphinx/CMakeLists.txt b/Utilities/Sphinx/CMakeLists.txt index 257ba62..256f1d5 100644 --- a/Utilities/Sphinx/CMakeLists.txt +++ b/Utilities/Sphinx/CMakeLists.txt @@ -156,18 +156,21 @@ if(SPHINX_MAN) if("x${m}" MATCHES "^x(.+)\\.([1-9])\\.rst$") set(name "${CMAKE_MATCH_1}") set(sec "${CMAKE_MATCH_2}") + set(_m_skip FALSE) if(NOT CMakeHelp_STANDALONE) if(name STREQUAL "ccmake" AND NOT BUILD_CursesDialog) - continue() -endif() -if(name STREQUAL "cmake-gui" AND NOT BUILD_QtDialog) - continue() + set(_m_skip TRUE) +elseif(name STREQUAL "cmake-gui" AND NOT BUILD_QtDialog) + set(_m_skip TRUE) endif() endif() - CMake_OPTIONAL_COMPONENT(sphinx-man) - install(FILES ${CMAKE_CURRENT_BINARY_DIR}/man/${name}.${sec} - DESTINATION ${CMAKE_MAN_DIR}/man${sec} - ${COMPONENT}) + if(NOT _m_skip) +CMake_OPTIONAL_COMPONENT(sphinx-man) +install(FILES ${CMAKE_CURRENT_BINARY_DIR}/man/${name}.${sec} +DESTINATION ${CMAKE_MAN_DIR}/man${sec} +${COMPONENT}) + endif() + unset(_m_skip) endif() endforeach() endif() -- 2.8.3.windows.1 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH v4 4/4] For Windows encode process output to internally used encoding
2016-08-02 20:11 GMT+03:00 Brad King: > > How are we to know the encoding being produced by the child? > There isn't any reliable way to detect it, we just have to know what particular application uses. Also there aren't any standard or API to determine it but generally most applications use console's code page. Of course not all, it could be OEM, ANSI or something else. If application uses console's code page for pipes then app.exe | echo will output correctly in cmd and piping in other application which also uses it will work. Here our issue is that when CMake checks for compiler path it gets output from MSVC and it will give this path in console's codepage which will be incorrectly interpreted as UTF-8 so we need to decode it first. If there will some other application which uses different encoding then it will need separate handling for that. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Use full path for all source files in ninja build.
The relative path is used whenever the build directory is under the source directory (e.g., under src/build/), so it could still be out of source. > FWIW, I haven't encountered any problems with Vim's :make with CMake's > generated Ninja files in out-of-source builds for in-source or generated > files (I almost never do in-source builds). Interesting. It appears that if you do :set makeprg=ninja\ -C\ /path/to/build | make then ninja will output this: > ninja: Entering directory `/path/to/build' and vim interprets that to be the working directory. However, if you use these: :set makeprg=cd\ /path/to/build\ &&\ ninja | make :set makeprg=cmake\ --build\ /path/to/build | make then the "Entering directory" line wouldn't appear, and vim won't know what to do. Our IDE uses "cmake --build /path/to/build" to invoke the build, so that we only have to deal with CMake and not the underlying build system. Compilers know the absolute path to all the files in a translation unit > since the preprocessor was able to read them. They could be taught to > produce absolute paths in their error messages to work better for IDEs > regardless of how the build system invokes them. I would love to see this too, but it's much easier to fix the problem in one place (CMake, or even just Ninja), than to fix that for every compiler. Maybe I can try to fix ninja to resolve paths before sending them to the compiler. Or maybe just add a flag to ConvertToNinjaPath or something. On Tue, Aug 2, 2016 at 11:33 AM, Ben Boeckelwrote: > On Tue, Aug 02, 2016 at 11:11:44 -0700, Chaoren Lin via cmake-developers > wrote: > > Similarly, the :make command in vim will have no knowledge of > build.gradle, > > and only tries to parse the build errors directly. > > FWIW, I haven't encountered any problems with Vim's :make with CMake's > generated Ninja files in out-of-source builds for in-source or generated > files (I almost never do in-source builds). > > --Ben > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [Patch 3/5] Improved WIX support
On 07/20/2016 03:58 PM, Stuermer, Michael SP/HZA-ZSEP wrote: Using the patchfile support I managed to implement the service installation issue I had, so the unnecessary features from the last patch are removed now. I tested all patches separately and hope they work now. looking forward for feedback, best regrads, Michael Patch 3 looks OK but I think I would prefer using WiX over CPack nomenclature in the variables you introduce. e.g. CPACK_WIX_ROOT_FEATURE_TITLE and CPACK_WIX_ROOT_FEATURE_DESCRIPTION over CPACK_WIX_ROOT_COMPONENT_DISPLAY_NAME and CPACK_WIX_ROOT_COMPONENT_DESCRIPTION given that CPack has no concept of a root component. Would you agree? Nils -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake -E capabilities [attempt 2]
Tobias Hunger wrote: > Hi Stephen, > > thanks for taking the time to do such a thorough review! Actually my review wasn't thorough at all. I didn't try to review it further. The NewFactory methods in your patch don't return a new'd object, but instead return static locals. The regular generators NewFactory methods don't work that way, so you're introducing a pattern which is different to what already exists and the commit message doesn't say why. Maybe there's a reason, but I don't know what it is. In the future, no one else will know either. There are lots of things in there for which your intent is unclear. That's why splitting and writing descriptive commit messages is valuable. You might find https://vimeo.com/172882423 to be a good introduction to this. I have more to ask about your first commit (and why the second commit is split out). I stopped my review at recommending it be split to see what it is hiding. > Added const to some of them:-) Hope I caught all. cmake::ReportCapabilities() should be const, right? >> * and a whitespace change that should be squashed into the commit that >> introduces it > > I used Utilities/Scripts/clang-format.bash to do the formatting, so > that should not be an issue. I just reran that on all commits. Maybe I > forgot it in a commit or something before. Maybe. Running the script on all commits would be the fix anyway. >> * The CMAKE_BUILD_WITH_CMAKE macro should be in cmcmd.cxx wrapping the >> capabilities handling: >> >> #if defined(CMAKE_BUILD_WITH_CMAKE) >> else if (args[1] == "capabilities") { >> cmake cm; >> std::cout << cm.ReportCapabilities(); >> return 0; >> } >> #endif > > Why? Because it's a bit odd to return 0 if capabilities can't be reported. I missed that the contents of that method don't compile in bootstrap mode though without the define. >> As it is, it is doing many different things, none of which are mentioned >> in the commit message, and some of which it probably shouldn't be doing. >> >> For example renaming GetExtraGeneratorName to >> GetExternalMakefileProjectGeneratorName is probably not needed. If you >> really want to do it, then it should be in its own commit with its own >> commit message which justifies the change. As it is, it adds noise to the >> big commit and makes it harder to review. Minimal is always better with >> commits which do refactoring like that. > > I undid that change. That is one of the things that I originally > removed and then realized last minute that it is needed somehow. So I > added it, not realizing that I had removed similar functionality > earlier. This doesn't happen if you split commits. Splitting makes these things visible to you and you can decide whether they were intentional or not at that point. >> A general good rule of thumb (which helps reviews, and makes things >> bisectable in the future) is to do one thing per commit. > > I agree that this is the ideal we all should all strive for, but you > are not going to get that from me anytime soon. Calling it an 'ideal' isn't really the right mindset. It's easy, and it's generally done by all other cmake contributors. > At least not in the cmake codebase. I don't know what this part means. It seems somehow disdainful, but I might be missing something. Something to talk about in person perhaps. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers