[Cmake-commits] CMake branch, master, updated. v3.13.0-rc1-43-ga359812
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via a35981249d9efbf3db943698a1258ac6cbf3a5d5 (commit) from b57560bb0fcb30cefe681c79a75ff29c43ee3931 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a35981249d9efbf3db943698a1258ac6cbf3a5d5 commit a35981249d9efbf3db943698a1258ac6cbf3a5d5 Author: Kitware Robot AuthorDate: Wed Oct 10 00:01:07 2018 -0400 Commit: Kitware Robot CommitDate: Wed Oct 10 00:01:07 2018 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 7466205..6a2cb16 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -1,5 +1,5 @@ # CMake version number components. set(CMake_VERSION_MAJOR 3) set(CMake_VERSION_MINOR 13) -set(CMake_VERSION_PATCH 20181009) +set(CMake_VERSION_PATCH 20181010) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org https://cmake.org/mailman/listinfo/cmake-commits
Re: [CMake] support for -fsyntax-only (and generating Qt/KDE's auto-generated content)
Are you thinking of tools that are invoked instead of the compiler, like clazy- standalone? I thought about mentioning a potential interest of my idea for using such tools (but forgot in the end). Yes, that and all the other tools supported by CMake as a "pre-command" before the compiler invocation (e.g. clang-tidy, iwyu,...) Specific support for -fsyntax-only may not be relevant for those tools, but a build mode where the final step of each build product is not taken would probably be useful there, indeed. Such a mode might even create an empty file with the intended name, so that there's something to refer to later during a build. I've been considering to write a little wrapper one could "inject" using CMAKE__COMPILER_LAUNCHER but there is no equivalent for the final product generation step (linker, librarian). So if we can achieve a light build mode, that would be great. In my case I could completely deactivate the build part including the syntax checking since that's done by the static analysis tools anyway. You'd get that by setting your analysis tool as the compiler. I did not think of doing that. I'll have to play with it, but I think the final product step will still be an issue. Sylvain -- 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: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] support for -fsyntax-only (and generating Qt/KDE's auto-generated content)
Sylvain Joubert wrote: > My use case is for static analysis builds. For example, my CI setup has > multiple of them including cppcheck, clang-tidy and iwyu through the > CMake integration. And since I'd like to keep separate builds for each > of them this requires 3 full build whose results I don't really care. Are you thinking of tools that are invoked instead of the compiler, like clazy- standalone? I thought about mentioning a potential interest of my idea for using such tools (but forgot in the end). Specific support for -fsyntax-only may not be relevant for those tools, but a build mode where the final step of each build product is not taken would probably be useful there, indeed. Such a mode might even create an empty file with the intended name, so that there's something to refer to later during a build. I've been considering to write a little wrapper one could "inject" using CMAKE__COMPILER_LAUNCHER but there is no equivalent for the final product generation step (linker, librarian). > > So if we can achieve a light build mode, that would be great. In my case > I could completely deactivate the build part including the syntax > checking since that's done by the static analysis tools anyway. You'd get that by setting your analysis tool as the compiler. > Anyhow, we can't deactivate all the build. As you said auto-generated > content, custom targets,... would need to stay. And besides, cmake's goal is to create files with which one can build projects. Generating something that doesn't attempt to build at all could well require a lot more implementation effort than pretending the linker/librarian step always succeeds. FWIW, I notice that the link step now takes the form cmake -E cmake_link_script CMakeFiles/.dir/link.txt IOW there are 2 levels where linker errors due to missing objects can be intercepted: in the link.txt script, and in cmake itself. R. -- 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: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] [ANNOUNCE] CMake 3.13.0-rc1 is ready for testing
On 10/09/2018 02:00 PM, Rolf Eike Beer wrote: > Seems like you missed one part of the announcement mail ;) > > Policies > == The announcement comes from the release notes, and all policies are mentioned there in relevant bullets. We've never called them out separately in such notes. One can always see the list here: https://cmake.org/cmake/help/v3.13/manual/cmake-policies.7.html#policies-introduced-by-cmake-3-13 separated by version. -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: https://cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] [ANNOUNCE] CMake 3.13.0-rc1 is ready for testing
On 10/09/2018 02:00 PM, Rolf Eike Beer wrote: > Seems like you missed one part of the announcement mail ;) > > Policies > == The announcement comes from the release notes, and all policies are mentioned there in relevant bullets. We've never called them out separately in such notes. One can always see the list here: https://cmake.org/cmake/help/v3.13/manual/cmake-policies.7.html#policies-introduced-by-cmake-3-13 separated by version. -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: https://cmake.org/mailman/listinfo/cmake-developers
Re: [CMake] [cmake-developers] [ANNOUNCE] CMake 3.13.0-rc1 is ready for testing
Robert Maynard wrote:
> I am proud to announce the first CMake 3.13 release candidate.
> https://cmake.org/download/
>
> Documentation is available at:
> https://cmake.org/cmake/help/v3.13
>
> Release notes appear below and are also published at
> https://cmake.org/cmake/help/v3.13/release/3.13.html
>
> Some of the more significant changes in CMake 3.13 are:
[…]
Seems like you missed one part of the announcement mail ;)
Policies
==
* An explicit deprecation diagnostic was added for policies
"CMP0055" through "CMP0063" ("CMP0054" and below were already
deprecated). The "cmake-policies(7)" manual explains that the OLD
behaviors of all policies are deprecated and that projects should
port to the NEW behaviors.
* CMP0076: The ``target_sources()`` command converts relative paths to
absolute.
* CMP0077: ``option()`` honors normal variables.
* CMP0078: ``UseSWIG`` generates now standard target names.
* CMP0079: ``target_link_libraries()`` allows use with targets in other
directories.
* CMP0080: ``BundleUtilities`` cannot be included at configure time.
* CMP0081: Relative paths not allowed in ``LINK_DIRECTORIES`` target property.
HTH,
Eike
--
signature.asc
Description: This is a digitally signed message part.
--
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:
https://cmake.org/mailman/listinfo/cmake
Re: [cmake-developers] [ANNOUNCE] CMake 3.13.0-rc1 is ready for testing
Robert Maynard wrote:
> I am proud to announce the first CMake 3.13 release candidate.
> https://cmake.org/download/
>
> Documentation is available at:
> https://cmake.org/cmake/help/v3.13
>
> Release notes appear below and are also published at
> https://cmake.org/cmake/help/v3.13/release/3.13.html
>
> Some of the more significant changes in CMake 3.13 are:
[…]
Seems like you missed one part of the announcement mail ;)
Policies
==
* An explicit deprecation diagnostic was added for policies
"CMP0055" through "CMP0063" ("CMP0054" and below were already
deprecated). The "cmake-policies(7)" manual explains that the OLD
behaviors of all policies are deprecated and that projects should
port to the NEW behaviors.
* CMP0076: The ``target_sources()`` command converts relative paths to
absolute.
* CMP0077: ``option()`` honors normal variables.
* CMP0078: ``UseSWIG`` generates now standard target names.
* CMP0079: ``target_link_libraries()`` allows use with targets in other
directories.
* CMP0080: ``BundleUtilities`` cannot be included at configure time.
* CMP0081: Relative paths not allowed in ``LINK_DIRECTORIES`` target property.
HTH,
Eike
--
signature.asc
Description: This is a digitally signed message part.
--
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:
https://cmake.org/mailman/listinfo/cmake-developers
Re: [CMake] support for -fsyntax-only (and generating Qt/KDE's auto-generated content)
I'd also like something like that for another use case of mine which stumble upon the same limitations (compiler checks, linking and Qt generated content). My use case is for static analysis builds. For example, my CI setup has multiple of them including cppcheck, clang-tidy and iwyu through the CMake integration. And since I'd like to keep separate builds for each of them this requires 3 full build whose results I don't really care. So if we can achieve a light build mode, that would be great. In my case I could completely deactivate the build part including the syntax checking since that's done by the static analysis tools anyway. Thinking of that maybe we can completely disable the build invocation and add support for a "syntax only" analysis tool that would feats your need. Anyhow, we can't deactivate all the build. As you said auto-generated content, custom targets,... would need to stay. Sylvain Le 09/10/2018 à 16:38, René J.V. Bertin a écrit : Hi, Apologies, longish post ahead. I've tried to present my idea and the thought train leading up to it as succinctly as possible. Hope I at least strike a chord! Clang and GCC have long supported an option that makes them stop after the syntax-verification stage: -fsyntax-only . This has the advantage (see below) that it's much faster than a regular build and that no output is generated. The absent output is also a problem and the reason I'm posting about it here: - compiler checking fails because of the missing output. - link and archive (static lib) creation fail because of missing files. The first problem should not be hard to fix (filter out -fsyntax-only from the arguments used to check the compiler). The 2nd problem can be addressed by ignoring the exit code from linking and archiving commands (possible with make, presumably with ninja too). Would it be feasible to implement "something" that makes it possible to run a full pure-syntax-checking "build", either as a special target or as a separate mode of operation or CMAKE_BUILD_TYPE? I think this could be useful in general esp. with larger projects, allowing to check "quickly" if a change (triggering a full rebuild) breaks something. QtWebKit would be an appropriate example: it uses a central header to set the configuration preprocessor tokens so toggling even one of these switches causes *everything* to be rebuilt. Some more observations which outline a context where cmake-level support for a pure syntax-checking run would be beneficial (also the context that made me remember the -fsyntax-only option): - a number of IDEs (can) use CMake as the basis for project definition. - They also provide parsing facilities that also use information from cmake to control the parser. - KDE has long used cmake instead of autoconf (or qmake) and is based on Qt, which means KDE projects depend on auto-generation of files which need to be included in C++ code. - Parsing or even syntax-checking won't work to at least some degree without those auto-generated files. - opening a project in an IDE is not always done with the intention to build it; in absence of such an intention one usually does expect to be able to rely on parsing and syntax checking. - Auto-generation of Qt's automatic content occurs during a full build, when needed. That last observation is the big bottleneck; a full build can be very costly. If there were a dedicated target to generate just all automatic content one could just build that target and there would be no issue left. Whether or not this is impossible is unclear, and at least not entirely a CMake issue. Here too something like -DCMAKE_BUILD_TYPE=SyntaxOnly would be a workable solution. R. -- 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: https://cmake.org/mailman/listinfo/cmake
[CMake] [ANNOUNCE] CMake 3.13.0-rc1 is ready for testing
I am proud to announce the first CMake 3.13 release candidate. https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.13 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.13/release/3.13.html Some of the more significant changes in CMake 3.13 are: * The Visual Studio Generators for VS 2010 and above learned to support the "INTERPROCEDURAL_OPTIMIZATION" target property and supporting "CheckIPOSupported" module. * The "Green Hills MULTI" generator has been updated to include support for platform, architecture, and toolset selection. * The "cmake" command gained the "-S " command line option to specify the location of the source directory. This option can be used independently of "-B". * The "cmake" command gained the "-B " command line option to specify the location of the build directory. This option can be used independently of "-S". * The "cmake" "-E create_symlink" command can now be used on Windows. * The "target_link_directories()" command was created to specify link directories for targets and their dependents. * The "target_link_options()" command was created to specify link options for targets and their dependents. * The "target_link_libraries()" command may now be called to modify targets created outside the current directory. See policy "CMP0079". * The "install(TARGETS)" command learned to install targets created outside the current directory. * The "install(CODE)" and "install(SCRIPT)" commands learned to support generator expressions. * A "VS_DEBUGGER_COMMAND_ARGUMENTS" target property was created to set the debugging command line arguments with Visual Studio Generators for VS 2010 and above. * A "VS_DEBUGGER_ENVIRONMENT" target property was created to set the debugging environment with Visual Studio Generators for VS 2010 and above. * The "option()" command now honors an existing normal variable of the same name and does nothing instead of possibly creating a cache entry (or setting its type) and removing the normal variable. See policy "CMP0077". * The "target_sources()" command now interprets relative source file paths as relative to the current source directory. This simplifies incrementally building up a target's sources from subdirectories. The "CMP0076" policy was added to provide backward compatibility with the old behavior where required. CMake 3.13 Release Notes Changes made since CMake 3.12 include the following. New Features Generators -- * The Visual Studio Generators for VS 2010 and above learned to support the "INTERPROCEDURAL_OPTIMIZATION" target property and supporting "CheckIPOSupported" module. * The "Xcode" generator learned to configure more Xcode Scheme fields. See the "CMAKE_XCODE_GENERATE_SCHEME" variable. * The "Green Hills MULTI" generator has been updated: * Added support for architecture selection through "CMAKE_GENERATOR_PLATFORM": e.g. "arm", "ppc", and "86". * Added support for toolset selection through "CMAKE_GENERATOR_TOOLSET", e.g. "comp_201205", "comp_201510", "comp_201722_beta". * Added support for platform selection through "GHS_TARGET_PLATFORM", e.g. "integrity", "linux", "standalone", etc. * No longer checks that "arm" based compilers are installed but ensures that the correct "gbuild.exe" exists. * No longer hard-codes ARM files, BSP, toolset, or OS locations. Command-Line * The "cmake(1)" command gained the "-S " command line option to specify the location of the source directory. This option can be used independently of "-B". * The "cmake(1)" command gained the "-B " command line option to specify the location of the build directory. This option can be used independently of "-S". * The "cmake(1)" "-E create_symlink" command can now be used on Windows. Commands * The "add_custom_command()" and "add_custom_target()" commands learned to support generator expressions in "WORKING_DIRECTORY" options. * The "add_link_options()" command was created to add link options in the current directory. * The "install(CODE)" and "install(SCRIPT)" commands learned to support generator expressions. * The "install(TARGETS)" command learned to install targets created outside the current directory. * The "link_directories()" command gained options to control insertion position. * The "list(SORT)" command gained options to control the comparison operation used to order the entries. * The "math()" command gained options for hexadecimal. * The "target_link_directories()" command was created to specify link directories for targets and their dependents. * The "target_link_options()" command was created to specify link options for targets and their dependents. * The "target_link_libraries()" command may now be called to modify targets created outside the current directory.
[cmake-developers] [ANNOUNCE] CMake 3.13.0-rc1 is ready for testing
I am proud to announce the first CMake 3.13 release candidate. https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.13 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.13/release/3.13.html Some of the more significant changes in CMake 3.13 are: * The Visual Studio Generators for VS 2010 and above learned to support the "INTERPROCEDURAL_OPTIMIZATION" target property and supporting "CheckIPOSupported" module. * The "Green Hills MULTI" generator has been updated to include support for platform, architecture, and toolset selection. * The "cmake" command gained the "-S " command line option to specify the location of the source directory. This option can be used independently of "-B". * The "cmake" command gained the "-B " command line option to specify the location of the build directory. This option can be used independently of "-S". * The "cmake" "-E create_symlink" command can now be used on Windows. * The "target_link_directories()" command was created to specify link directories for targets and their dependents. * The "target_link_options()" command was created to specify link options for targets and their dependents. * The "target_link_libraries()" command may now be called to modify targets created outside the current directory. See policy "CMP0079". * The "install(TARGETS)" command learned to install targets created outside the current directory. * The "install(CODE)" and "install(SCRIPT)" commands learned to support generator expressions. * A "VS_DEBUGGER_COMMAND_ARGUMENTS" target property was created to set the debugging command line arguments with Visual Studio Generators for VS 2010 and above. * A "VS_DEBUGGER_ENVIRONMENT" target property was created to set the debugging environment with Visual Studio Generators for VS 2010 and above. * The "option()" command now honors an existing normal variable of the same name and does nothing instead of possibly creating a cache entry (or setting its type) and removing the normal variable. See policy "CMP0077". * The "target_sources()" command now interprets relative source file paths as relative to the current source directory. This simplifies incrementally building up a target's sources from subdirectories. The "CMP0076" policy was added to provide backward compatibility with the old behavior where required. CMake 3.13 Release Notes Changes made since CMake 3.12 include the following. New Features Generators -- * The Visual Studio Generators for VS 2010 and above learned to support the "INTERPROCEDURAL_OPTIMIZATION" target property and supporting "CheckIPOSupported" module. * The "Xcode" generator learned to configure more Xcode Scheme fields. See the "CMAKE_XCODE_GENERATE_SCHEME" variable. * The "Green Hills MULTI" generator has been updated: * Added support for architecture selection through "CMAKE_GENERATOR_PLATFORM": e.g. "arm", "ppc", and "86". * Added support for toolset selection through "CMAKE_GENERATOR_TOOLSET", e.g. "comp_201205", "comp_201510", "comp_201722_beta". * Added support for platform selection through "GHS_TARGET_PLATFORM", e.g. "integrity", "linux", "standalone", etc. * No longer checks that "arm" based compilers are installed but ensures that the correct "gbuild.exe" exists. * No longer hard-codes ARM files, BSP, toolset, or OS locations. Command-Line * The "cmake(1)" command gained the "-S " command line option to specify the location of the source directory. This option can be used independently of "-B". * The "cmake(1)" command gained the "-B " command line option to specify the location of the build directory. This option can be used independently of "-S". * The "cmake(1)" "-E create_symlink" command can now be used on Windows. Commands * The "add_custom_command()" and "add_custom_target()" commands learned to support generator expressions in "WORKING_DIRECTORY" options. * The "add_link_options()" command was created to add link options in the current directory. * The "install(CODE)" and "install(SCRIPT)" commands learned to support generator expressions. * The "install(TARGETS)" command learned to install targets created outside the current directory. * The "link_directories()" command gained options to control insertion position. * The "list(SORT)" command gained options to control the comparison operation used to order the entries. * The "math()" command gained options for hexadecimal. * The "target_link_directories()" command was created to specify link directories for targets and their dependents. * The "target_link_options()" command was created to specify link options for targets and their dependents. * The "target_link_libraries()" command may now be called to modify targets created outside the current directory.
[Cmake-commits] CMake branch, master, updated. v3.13.0-rc1-42-gb57560b
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via b57560bb0fcb30cefe681c79a75ff29c43ee3931 (commit) via af6f16f1e8a820ff5a08dfa273ceaa309fed7461 (commit) via ae80271ed35469d4d1092beb9665837963ba22ad (commit) from 517cc8e1ef8b3471dac452f494cf56889b92d1a0 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b57560bb0fcb30cefe681c79a75ff29c43ee3931 commit b57560bb0fcb30cefe681c79a75ff29c43ee3931 Merge: 517cc8e af6f16f Author: Brad King AuthorDate: Tue Oct 9 16:02:17 2018 + Commit: Kitware Robot CommitDate: Tue Oct 9 12:02:23 2018 -0400 Merge topic 'readme-build-docs' af6f16f1e8 README: Explain how to build CMake with the docs ae80271ed3 README: Fix typo (rm space). Acked-by: Kitware Robot Merge-request: !2466 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=af6f16f1e8a820ff5a08dfa273ceaa309fed7461 commit af6f16f1e8a820ff5a08dfa273ceaa309fed7461 Author: Joachim Wuttke (o) AuthorDate: Tue Oct 9 13:26:50 2018 +0200 Commit: Joachim Wuttke (o) CommitDate: Tue Oct 9 17:57:32 2018 +0200 README: Explain how to build CMake with the docs diff --git a/README.rst b/README.rst index 2e271ed..1e8561a 100644 --- a/README.rst +++ b/README.rst @@ -83,6 +83,13 @@ For instructions how to do this, see documentation on `Running CMake`_. .. _`Running CMake`: https://cmake.org/cmake/help/runningcmake.html +To build the documentation, install `Sphinx`_ and configure CMake with +``-DSPHINX_HTML=ON`` and/or ``-DSPHINX_MAN=ON`` to enable the "html" or +"man" builder. Add ``-DSPHINX_EXECUTABLE=/path/to/sphinx-build`` if the +tool is not found automatically. + +.. _`Sphinx`: http://sphinx-doc.org + Reporting Bugs == https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ae80271ed35469d4d1092beb9665837963ba22ad commit ae80271ed35469d4d1092beb9665837963ba22ad Author: Joachim Wuttke (o) AuthorDate: Tue Oct 9 09:58:30 2018 +0200 Commit: Joachim Wuttke (o) CommitDate: Tue Oct 9 13:26:17 2018 +0200 README: Fix typo (rm space). diff --git a/README.rst b/README.rst index f1dbd9d..2e271ed 100644 --- a/README.rst +++ b/README.rst @@ -68,7 +68,7 @@ Windows ^^^ You need to download and install a binary release of CMake in order to build -CMake. You can get these releases from the `CMake Download Page`_ . Then +CMake. You can get these releases from the `CMake Download Page`_. Then proceed with the instructions below. .. _`CMake Download Page`: https://cmake.org/cmake/resources/software.html --- Summary of changes: README.rst | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org https://cmake.org/mailman/listinfo/cmake-commits
Re: [CMake] Qt 5, macOS, bundle install
I found the solution!!
I just add the plugins attached to the Qt Component (in my case Qt5Widgets) and
install it:
set(qtplugins)
foreach(plugin ${Qt5Widgets_PLUGINS})
get_target_property(_loc ${plugin} LOCATION)
list(APPEND qtplugins ${_loc})
endforeach()
install_qt5_executable("${exe}" "${qtplugins}" "" "${dirs}" "")
I found a part of the solution in the Qt documentation
(http://doc.qt.io/qt-5/cmake-manual.html#imported-targets
).
How can I add this simple example inside the CMake example/tutorial?
Romain--
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:
https://cmake.org/mailman/listinfo/cmake
[CMake] support for -fsyntax-only (and generating Qt/KDE's auto-generated content)
Hi, Apologies, longish post ahead. I've tried to present my idea and the thought train leading up to it as succinctly as possible. Hope I at least strike a chord! Clang and GCC have long supported an option that makes them stop after the syntax-verification stage: -fsyntax-only . This has the advantage (see below) that it's much faster than a regular build and that no output is generated. The absent output is also a problem and the reason I'm posting about it here: - compiler checking fails because of the missing output. - link and archive (static lib) creation fail because of missing files. The first problem should not be hard to fix (filter out -fsyntax-only from the arguments used to check the compiler). The 2nd problem can be addressed by ignoring the exit code from linking and archiving commands (possible with make, presumably with ninja too). Would it be feasible to implement "something" that makes it possible to run a full pure-syntax-checking "build", either as a special target or as a separate mode of operation or CMAKE_BUILD_TYPE? I think this could be useful in general esp. with larger projects, allowing to check "quickly" if a change (triggering a full rebuild) breaks something. QtWebKit would be an appropriate example: it uses a central header to set the configuration preprocessor tokens so toggling even one of these switches causes *everything* to be rebuilt. Some more observations which outline a context where cmake-level support for a pure syntax-checking run would be beneficial (also the context that made me remember the -fsyntax-only option): - a number of IDEs (can) use CMake as the basis for project definition. - They also provide parsing facilities that also use information from cmake to control the parser. - KDE has long used cmake instead of autoconf (or qmake) and is based on Qt, which means KDE projects depend on auto-generation of files which need to be included in C++ code. - Parsing or even syntax-checking won't work to at least some degree without those auto-generated files. - opening a project in an IDE is not always done with the intention to build it; in absence of such an intention one usually does expect to be able to rely on parsing and syntax checking. - Auto-generation of Qt's automatic content occurs during a full build, when needed. That last observation is the big bottleneck; a full build can be very costly. If there were a dedicated target to generate just all automatic content one could just build that target and there would be no issue left. Whether or not this is impossible is unclear, and at least not entirely a CMake issue. Here too something like -DCMAKE_BUILD_TYPE=SyntaxOnly would be a workable solution. R. -- 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: https://cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake annotated tag, v3.13.0-rc1, created. v3.13.0-rc1
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The annotated tag, v3.13.0-rc1 has been created at d6970c9958255521fa22d1abffd3210b3860e6eb (tag) tagging 6784acfbe0fde03b577ab814946b309821ca6242 (commit) replaces v3.12.3 tagged by Brad King on Tue Oct 9 10:18:06 2018 -0400 - Log - CMake 3.13.0-rc1 -BEGIN PGP SIGNATURE- iQJKBAABCgA0FiEExsJlMku+vcNQtRPQLSzvEDSSFoQFAlu8uJ4WHGJyYWQua2lu Z0BraXR3YXJlLmNvbQAKCRAtLO8QNJIWhPzpD/9bHffQMcRZIatQWxR3aT0zGpoy xO29z6uvCzNOttSVOjz1m81FASwg6UGFerjXpW1OFM3jkTwY2/A6jReFGOu6ZqPs gYDE/yk7SkZRCjzZWLDNtbpMLxcNU0FNyN9tsfCBLbEB50cRL/AcW3XH3XsyLnJC ukEmTI/j0fw2/D+eRFbf/+qXGc42zgSHjcYYTsGThZgwa+LHqkYFLc3yxaFbIsii RH9zZxz8vnmt8WPUSJapGj+5LNo0gCuZtaU56L7tEz7JVMUJO7tMQGognF0af8lA 4y5mNLH2fJpcPaJwVOhvJiYHjf0+sf/Zu8U5YuiRQX5CIvRsonZ4x/25YWbRyKqz OfpwYVrD0tySGa4/XKHh96f+LcWtju2kz3RNHWO99EuSyoQItGnDHjMV9alZc8EK NZBJNPqF6D6RNFu9FM7H43uvCjLisohayk+LCfdsT5XvQZrlmoKBUnDom11gyWnh bRxc0+6HqPd7ylCC8sLrH3fSyEUUiXa0B26n2A9NlfQoUErdxwzS8D4osPXGoP2f 2kPO9ut9lyFXsgrdG4Qaqt8qHw6CRKMkyvMCAznZDL2Hc6gXi23Q/ErMpAu86oUm yCkm6CH5reIurnbMhBCOPv3hcyx2jIc3YVbENXNvlQGpX5/6B48ZpppPZC2Et/2C /yPUAuScwlq/9Yl1Kw== =7ItZ -END PGP SIGNATURE- Adam Oleksy (1): Extra Generator: Fix handling of CMAKE__COMPILER_ARG1 Alessandro (1): GoogleTest: gtest_add_tests() fails if any source file is empty Andreas Schneider (1): FindZLIB: Fix path detection via ProgramFiles env variables Andrew Fuller (4): CPack/Deb: Support SOURCE_DATE_EPOCH when packaging files Help: Fix typo CPack/Deb: Use CMAKE_COMMAND to set the environment CPack/Deb: Add ability to split out debug symbols into .ddeb package André Apitzsch (4): Protobuf: use upstream implementation to generate cpp and python files Protobuf: restore 'PROTOBUF_IMPORT_DIRS' check Protobuf: restore 'DESCRIPTORS' support Protobuf: restore previous output directory Anton Myagkov (1): FindOpenCL: Search per-architecture path suffixes on UNIX Bartosz Kosiorek (5): Help: Replace occurrences of "Mac OS X" with "macOS" Replace occurrences of "Mac OS X" with "macOS" in comments FindJNI: Add Ubuntu 18.04 path to java-11-openjdk FindJNI: Update module documentation FindJava: Update module documentation Bastien Schatt (1): VS: Disallow ReferenceOutputAssembly in ProjectReference if not possible Betsy McPhail (3): Help: Add RETURN_VALUE as an option to ctest_submit(CDASH_UPLOAD ctest_memcheck: Change failure to find log file from error to warning Help: Add CAPTURE_CMAKE_ERROR to ctest_submit and ctest_update documentation Brad King (397): Merge branch 'release-3.12' Begin post-3.12 development Merge topic 'install-code-script-genex' Merge topic 'ninja-win-rsp' Merge topic 'CMakePackageConfigHelpers-doc' Merge branch 'release-3.12' Merge topic 'LINK_OPTIONS' Merge topic 'FindPython-3.8' Merge branch 'release-3.12' Merge branch 'restore-windows-resources-through-link' into release-3.11 Merge topic 'restore-windows-resources-through-link' Merge branch 'release-3.11' Merge topic 'UseSWIG-handle-SWIG_MODULE_NAME' Merge topic 'UseSWIG-fix-genex' Merge topic 'UseSWIG-csharp-variant' Merge topic 'sphinx-info' Merge branch 'release-3.12' CMake 3.11.4 Merge branch 'release-3.11' Merge branch 'upstream-KWSys' into update-kwsys Merge topic 'list_sort' Merge topic 'UseSWIG-bugfixes' Merge topic 'update-kwsys' Merge topic 'find_program-conditional-cwd' Merge topic 'FindCURL-target-name' Merge topic 'xcode-10-archs' Merge branch 'release-3.12' Merge topic 'install_from_another_directory' Merge topic 'xcode-10-legacy-build-system' Merge topic 'vs-cuda-maxrregcount' Merge topic 'vs-cuda-no-host-includes' Merge branch 'release-3.12' Merge topic 'LINK_OPTIONS' Help: Update old version release notes for CPack generator docs Merge topic 'FindJPEG-fix-debug' Merge branch 'release-3.12' Merge topic 'vs_debugger' Merge topic 'cmake_autogen_verbose' Merge topic 'cpack-generator-documentation' Merge branch 'upstream-KWSys' into update-kwsys Update use of KWSys SystemTools::SplitString for new signature Tests: Adopt wizard test in RunCMake.CommandLine Merge topic 'file-GLOB-remove-new-errors' Merge topic 'vs-filter-default-toolset' Merge branch 'release-3.12' Merge topic 'test-wizard' Merge topic 'update-kwsys' Merge topic 'libuv-new-version-file-location' Merge branch 'release-3.12' Merge topic 'FindMatlab-doc-mcr' Merge topic 'lexer-null' Merge topic
[Cmake-commits] CMake branch, master, updated. v3.13.0-rc1-39-g517cc8e
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via 517cc8e1ef8b3471dac452f494cf56889b92d1a0 (commit) via 6784acfbe0fde03b577ab814946b309821ca6242 (commit) from d96aa163109514608ee7c1113e283f4fef0e85a4 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=517cc8e1ef8b3471dac452f494cf56889b92d1a0 commit 517cc8e1ef8b3471dac452f494cf56889b92d1a0 Merge: d96aa16 6784acf Author: Brad King AuthorDate: Tue Oct 9 10:16:35 2018 -0400 Commit: Brad King CommitDate: Tue Oct 9 10:16:35 2018 -0400 Merge branch 'release-3.13' --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org https://cmake.org/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, release, updated. v3.13.0-rc1
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, release has been updated via 6784acfbe0fde03b577ab814946b309821ca6242 (commit) from f6193d92fd6c99db81126bd8ff812797ed629be9 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org https://cmake.org/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.12.3-875-gd96aa16
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via d96aa163109514608ee7c1113e283f4fef0e85a4 (commit) via afd5d17bace86149e2b99dca3cd1a51691318b34 (commit) via f6193d92fd6c99db81126bd8ff812797ed629be9 (commit) via c64797fa94de29ef3f5f9c940273036c9ebf64ee (commit) from 577a9a88ad832c35982814b7c485cbebc89fffb9 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d96aa163109514608ee7c1113e283f4fef0e85a4 commit d96aa163109514608ee7c1113e283f4fef0e85a4 Merge: afd5d17 f6193d9 Author: Brad King AuthorDate: Tue Oct 9 09:03:52 2018 -0400 Commit: Brad King CommitDate: Tue Oct 9 09:03:52 2018 -0400 Merge branch 'release-3.13' https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=afd5d17bace86149e2b99dca3cd1a51691318b34 commit afd5d17bace86149e2b99dca3cd1a51691318b34 Merge: 577a9a8 c64797f Author: Brad King AuthorDate: Tue Oct 9 13:03:04 2018 + Commit: Kitware Robot CommitDate: Tue Oct 9 09:03:10 2018 -0400 Merge topic 'FindBISON-fix-verbose-file' c64797fa94 FindBISON: Fix "multiple rules generate" error on VERBOSE output Acked-by: Kitware Robot Merge-request: !2467 --- Summary of changes: Modules/FindBISON.cmake | 21 ++--- 1 file changed, 14 insertions(+), 7 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org https://cmake.org/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, release, updated. v3.12.3-837-gf6193d9
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, release has been updated via f6193d92fd6c99db81126bd8ff812797ed629be9 (commit) via c64797fa94de29ef3f5f9c940273036c9ebf64ee (commit) from 54f0ae5414632043ede652797d6c200e6c57dc26 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - --- Summary of changes: Modules/FindBISON.cmake | 21 ++--- 1 file changed, 14 insertions(+), 7 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org https://cmake.org/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.12.3-871-g577a9a8
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via 577a9a88ad832c35982814b7c485cbebc89fffb9 (commit) via 03e381cb8a95b804ee30f94130a5f07ab2a00768 (commit) via 54f0ae5414632043ede652797d6c200e6c57dc26 (commit) via f23760ffac85f4cee6206c654265df9b3a46bf90 (commit) from 092a0b104a4aa1c4e6df5db11fab5221fd1e9331 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=577a9a88ad832c35982814b7c485cbebc89fffb9 commit 577a9a88ad832c35982814b7c485cbebc89fffb9 Merge: 03e381c 54f0ae5 Author: Brad King AuthorDate: Tue Oct 9 07:43:14 2018 -0400 Commit: Brad King CommitDate: Tue Oct 9 07:43:14 2018 -0400 Merge branch 'release-3.13' https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=03e381cb8a95b804ee30f94130a5f07ab2a00768 commit 03e381cb8a95b804ee30f94130a5f07ab2a00768 Merge: 092a0b1 f23760f Author: Brad King AuthorDate: Tue Oct 9 11:42:38 2018 + Commit: Kitware Robot CommitDate: Tue Oct 9 07:42:45 2018 -0400 Merge topic 'string-TIMESTAMP-unset-TZ' f23760ffac string(TIMESTAMP): Fix unset TZ Acked-by: Kitware Robot Acked-by: Attila Krasznahorkay Merge-request: !2464 --- Summary of changes: Source/cmTimestamp.cxx | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org https://cmake.org/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, release, updated. v3.12.3-835-g54f0ae5
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, release has been updated via 54f0ae5414632043ede652797d6c200e6c57dc26 (commit) via f23760ffac85f4cee6206c654265df9b3a46bf90 (commit) from efa5d5c781abb92e3a634541e89a72b0a520c65f (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - --- Summary of changes: Source/cmTimestamp.cxx | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org https://cmake.org/mailman/listinfo/cmake-commits
[CMake] Qt 5, macOS, bundle install
Hello everyone,
I try to install a bundle application on macOS.
I successfully create the bundle and add all dependencies to Qt event the
plugin platform libqcocoa.dylib.
Unfortunately, when I launch the installed app, the window style is not the
same as the build app style (macOS) as you can see on the joined
screenshots.
The CMakeLists.txt script is (too?) simple:
cmake_minimum_required(VERSION 3.2 FATAL_ERROR)
project(testProj)
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ${CMAKE_CURRENT_SOURCE_DIR})
set(CMAKE_AUTOMOC ON)
set(CMAKE_AUTOUIC_SEARCH_PATHS ${CMAKE_CURRENT_SOURCE_DIR}/ui)
set(CMAKE_AUTOUIC ON)
set(CMAKE_AUTORCC ON)
find_package(Qt5Core REQUIRED)
find_package(Qt5Widgets REQUIRED)
get_target_property(QtCore_location Qt5::Core LOCATION)
get_target_property(QtWidgets_location Qt5::Widgets LOCATION)
include_directories(${QtCore_location} ${QtWidgets_location})
add_executable(${PROJECT_NAME} MACOSX_BUNDLE main.cpp MainWindow.cpp
MainWindow.hpp MainWindow.ui)
set_target_properties(${PROJECT_NAME} PROPERTIES
CXX_STANDARD 14
CXX_STANDARD_REQUIRED YES
CXX_EXTENSIONS NO)
install(TARGETS ${PROJECT_NAME} DESTINATION ".")
target_link_libraries(${PROJECT_NAME} Qt5::Widgets)
set_target_properties(${PROJECT_NAME}
PROPERTIES
MACOSX_BUNDLE_BUNDLE_NAME "${PROJECT_NAME}"
)
include(InstallRequiredSystemLibraries)
include(DeployQt5)
get_target_property(build_dir ${PROJECT_NAME} BINARY_DIR)
get_target_property(target_name ${PROJECT_NAME} NAME)
get_target_property(isbundle ${PROJECT_NAME} MACOSX_BUNDLE)
get_filename_component(qt_dlls_dir "${QtWidgets_location}" PATH)
get_filename_component(qt_dlls_dir "${qt_dlls_dir}" PATH)
set(dirs "${qt_dlls_dir}")
if(WIN32)
set(suffix ".exe")
endif()
if (${isbundle})
set(exe ${target_name}.app)
else()
set(exe ${target_name}${suffix})
endif()
install_qt5_executable(${exe} "" "" "${dirs}" "" "")
I don't understand why the plugin libqcocoa.dylib is not used for the
installed app.
I try to read the CMake script available (such as Paraview or Slicer3D),
but it's a little too much time consuming.
Is there some simple example available?
Thank you,
Romain
<>
--
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:
https://cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, release, updated. v3.12.3-833-gefa5d5c
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, release has been updated via efa5d5c781abb92e3a634541e89a72b0a520c65f (commit) via fab2c2339b2b6a4310103f1fec74f6b8c55a8f01 (commit) via 92ed3b38cc892b3acb78d9b4f83c35375b854b00 (commit) via 0e2799019fcd207d1050fb89f0cdea579f9aff64 (commit) via bb60ed6e724b2891a33f3cd5b6e5aa300dcc4180 (commit) via d0fb3e6c522e656b121911d791defb46ddecbc3b (commit) via c268fcc2edf319bd420b8aa0fac21260e7f23291 (commit) via cd8c79e1633f091fca890df534d98e5eeb63b747 (commit) from c2356d60d8b3bc709ed5e95f98864ff504685010 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - --- Summary of changes: Help/command/string.rst| 19 Help/command/target_link_libraries.rst | 24 Modules/FindBLAS.cmake | 46 ++ Modules/FindLAPACK.cmake | 12 ++-- Source/cmVS141CLFlagTable.h| 2 ++ Source/cmVisualStudio10TargetGenerator.cxx | 8 ++ Source/cmVisualStudio10TargetGenerator.h | 1 + 7 files changed, 79 insertions(+), 33 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org https://cmake.org/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.12.3-867-g092a0b1
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via 092a0b104a4aa1c4e6df5db11fab5221fd1e9331 (commit) via efa5d5c781abb92e3a634541e89a72b0a520c65f (commit) via 92ed3b38cc892b3acb78d9b4f83c35375b854b00 (commit) via 0e2799019fcd207d1050fb89f0cdea579f9aff64 (commit) via c268fcc2edf319bd420b8aa0fac21260e7f23291 (commit) from 3ea9d81da6499b5828c68d0c694ce0579efc555f (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=092a0b104a4aa1c4e6df5db11fab5221fd1e9331 commit 092a0b104a4aa1c4e6df5db11fab5221fd1e9331 Merge: 3ea9d81 efa5d5c Author: Brad King AuthorDate: Tue Oct 9 06:35:20 2018 -0400 Commit: Brad King CommitDate: Tue Oct 9 06:35:20 2018 -0400 Merge branch 'release-3.13' --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org https://cmake.org/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.12.3-862-g3ea9d81
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".
The branch, master has been updated
via 3ea9d81da6499b5828c68d0c694ce0579efc555f (commit)
via fab2c2339b2b6a4310103f1fec74f6b8c55a8f01 (commit)
via 424851742e0fb550cdf19c6db0882fd9b15f779e (commit)
via e9114f5bcfa41c51e23277e1129f469a6344dd35 (commit)
via db8920a2c53d53133dd44f74c2d6cd77fac308a1 (commit)
via bb60ed6e724b2891a33f3cd5b6e5aa300dcc4180 (commit)
via d0fb3e6c522e656b121911d791defb46ddecbc3b (commit)
via cd8c79e1633f091fca890df534d98e5eeb63b747 (commit)
from 9df49ba020ebfa15571ce818631bed6043368c8e (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3ea9d81da6499b5828c68d0c694ce0579efc555f
commit 3ea9d81da6499b5828c68d0c694ce0579efc555f
Merge: 4248517 fab2c23
Author: Brad King
AuthorDate: Tue Oct 9 10:34:01 2018 +
Commit: Kitware Robot
CommitDate: Tue Oct 9 06:34:06 2018 -0400
Merge topic 'doc-regex-backslash'
fab2c2339b Help: Fix documentation of escape sequences in a regex
Acked-by: Kitware Robot
Merge-request: !2460
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fab2c2339b2b6a4310103f1fec74f6b8c55a8f01
commit fab2c2339b2b6a4310103f1fec74f6b8c55a8f01
Author: Brad King
AuthorDate: Mon Oct 8 11:46:22 2018 -0400
Commit: Brad King
CommitDate: Tue Oct 9 06:31:37 2018 -0400
Help: Fix documentation of escape sequences in a regex
Documentation added by commit 4b35dab891 (Help: Document how escape
sequences work in a regex, 2018-07-18) is only correct for backslashes
inside `[]` groups. The regex engine does interpret `\` escapes
elsewhere. Fix the docs.
Inspired-by: R2RT
Fixes: #18428
diff --git a/Help/command/string.rst b/Help/command/string.rst
index 29a153a..cc18069 100644
--- a/Help/command/string.rst
+++ b/Help/command/string.rst
@@ -121,6 +121,11 @@ The following characters have special meaning in regular
expressions:
Matches at end of input
``.``
Matches any single character
+``\``
+ Matches the single character specified by . Use this to
+ match special regex characters, e.g. ``\.`` for a literal ``.``
+ or ``\\`` for a literal backslash ``\``. Escaping a non-special
+ character is unnecessary but allowed, e.g. ``\a`` matches ``a``.
``[ ]``
Matches any character(s) inside the brackets
``[^ ]``
@@ -151,12 +156,9 @@ has lower precedence than concatenation. This means that
the regular
expression ``^ab+d$`` matches ``abbd`` but not ``ababd``, and the regular
expression ``^(ab|cd)$`` matches ``ab`` but not ``abd``.
-Backslash (``\``) characters in regular expressions are interpreted
-literally and do not escape anything or represent placeholders.
-However, CMake language :ref:`Escape Sequences` such as ``\t``,
-``\r``, ``\n``, and ``\\`` may be used to construct literal tabs,
-carriage returns, newlines, and backslashes (respectively) to pass
-in a regex. For example:
+CMake language :ref:`Escape Sequences` such as ``\t``, ``\r``, ``\n``,
+and ``\\`` may be used to construct literal tabs, carriage returns,
+newlines, and backslashes (respectively) to pass in a regex. For example:
* The quoted argument ``"[ \t\r\n]"`` specifies a regex that matches
any single whitespace character.
@@ -164,6 +166,11 @@ in a regex. For example:
a single forward slash ``/`` or backslash ``\``.
* The quoted argument ``"[A-Za-z0-9_]"`` specifies a regex that matches
any single "word" character in the C locale.
+* The quoted argument ``"\\(\\a\\+b\\)"`` specifies a regex that matches
+ the exact string ``(a+b)``. Each ``\\`` is parsed in a quoted argument
+ as just ``\``, so the regex itself is actually ``\(\a\+\b\)``. This
+ can alternatively be specified in a :ref:`bracket argument` without
+ having to escape the backslashes, e.g. ``[[\(\a\+\b\)]]``.
Manipulation
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=424851742e0fb550cdf19c6db0882fd9b15f779e
commit 424851742e0fb550cdf19c6db0882fd9b15f779e
Merge: e9114f5 d0fb3e6
Author: Brad King
AuthorDate: Tue Oct 9 10:27:34 2018 +
Commit: Kitware Robot
CommitDate: Tue Oct 9 06:27:55 2018 -0400
Merge topic 'mkl_ilp64'
d0fb3e6c52 Find{BLAS,LAPACK}: Find also ILP64 MKL BLAS and LAPACK
Acked-by: Kitware Robot
Merge-request: !2444
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e9114f5bcfa41c51e23277e1129f469a6344dd35
commit e9114f5bcfa41c51e23277e1129f469a6344dd35
Merge: db8920a bb60ed6
Author: Brad King
AuthorDate: Tue Oct 9 10:27:16 2018 +
Commit: Kitware Robot
CommitDate: Tue
[Cmake-commits] CMake branch, master, updated. v3.12.3-854-g9df49ba
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "CMake". The branch, master has been updated via 9df49ba020ebfa15571ce818631bed6043368c8e (commit) via ab6bf9d0adc3de143599d5558a6475af3ba172eb (commit) from 0ab5db035ed47182fb8551f9872045eeae1f9cec (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9df49ba020ebfa15571ce818631bed6043368c8e commit 9df49ba020ebfa15571ce818631bed6043368c8e Merge: 0ab5db0 ab6bf9d Author: Brad King AuthorDate: Tue Oct 9 10:24:28 2018 + Commit: Kitware Robot CommitDate: Tue Oct 9 06:24:34 2018 -0400 Merge topic 'update-prebuilt-openssl' ab6bf9d0ad Utilities/Release: Update to openssl-1.1.1 Acked-by: Kitware Robot Merge-request: !2461 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ab6bf9d0adc3de143599d5558a6475af3ba172eb commit ab6bf9d0adc3de143599d5558a6475af3ba172eb Author: Brad King AuthorDate: Mon Oct 8 10:42:12 2018 -0400 Commit: Brad King CommitDate: Mon Oct 8 10:42:12 2018 -0400 Utilities/Release: Update to openssl-1.1.1 Update the prebuilt binary build configurations for machines where we build our own OpenSSL library to use a newer version. diff --git a/Utilities/Release/linux64_release.cmake b/Utilities/Release/linux64_release.cmake index dc34120..fa585d7 100644 --- a/Utilities/Release/linux64_release.cmake +++ b/Utilities/Release/linux64_release.cmake @@ -29,9 +29,9 @@ CURSES_LIBRARY:FILEPATH=/home/kitware/ncurses-5.9/lib/libncurses.a CURSES_INCLUDE_PATH:PATH=/home/kitware/ncurses-5.9/include FORM_LIBRARY:FILEPATH=/home/kitware/ncurses-5.9/lib/libform.a CMAKE_USE_OPENSSL:BOOL=ON -OPENSSL_CRYPTO_LIBRARY:STRING=/home/kitware/openssl-1.1.0h/lib/libcrypto.a;-pthread -OPENSSL_INCLUDE_DIR:PATH=/home/kitware/openssl-1.1.0h/include -OPENSSL_SSL_LIBRARY:FILEPATH=/home/kitware/openssl-1.1.0h/lib/libssl.a +OPENSSL_CRYPTO_LIBRARY:STRING=/home/kitware/openssl-1.1.1/lib/libcrypto.a;-pthread +OPENSSL_INCLUDE_DIR:PATH=/home/kitware/openssl-1.1.1/include +OPENSSL_SSL_LIBRARY:FILEPATH=/home/kitware/openssl-1.1.1/lib/libssl.a PYTHON_EXECUTABLE:FILEPATH=/usr/bin/python3 CPACK_SYSTEM_NAME:STRING=Linux-x86_64 BUILD_CursesDialog:BOOL=ON --- Summary of changes: Utilities/Release/linux64_release.cmake | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org https://cmake.org/mailman/listinfo/cmake-commits
Re: [CMake] target_compile_flags and PUBLIC
Marc
Thank you. That fixes it.
JB
From: Marc CHEVRIER [marc.chevr...@gmail.com]
Sent: 09 October 2018 09:52
To: Biddiscombe, John A.
Cc: cmake@cmake.org
Subject: Re: [CMake] target_compile_flags and PUBLIC
Have a look at '$' and '$'
generator expressions.
Le mar. 9 oct. 2018 à 09:48, Biddiscombe, John A.
mailto:biddi...@cscs.ch>> a écrit :
I have a problem with exported flags from a project.
If I use `target_compile_options(hpx PUBLIC ${flags})` hpx is compiled with the
flags, and all 500+ tests within the project that depend on hpx inherit the
flags too, so they get built correctly. However, the `HPXTargets.cmake` file
that is generated with the exported targets, also inherits these flags and
lists them in INTERFACE_COMPILE_OPTIONS, so now users are complaining that
flags used to compile hpx are being passed onto their project and some of the
stuff we use like `-Werror=sign-compare` causes a build fail in their project.
If I use `target_compile_options(hpx PRIVATE ${flags})` then the flags are not
passed on to the user projects, but also not passed on to the tests either. Is
there an easy way of saying, pass these flags to all my projects within this
'PROJECT' but don't export them via the PUBLIC/INTERFACE to 3rd party users?
Thanks
JB
--
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:
https://cmake.org/mailman/listinfo/cmake
--
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:
https://cmake.org/mailman/listinfo/cmake
Re: [CMake] target_compile_flags and PUBLIC
Hi John,
you could put those flags as PUBLIC into a separate INTERFACE target (let's
call it hpxFlags) and then do
target_libraries(hpx PRIVATE hpxFlags)
Then create another interface target hpxForTests to combine those two
targets:
target_link_libraries(hpxForTests PUBLIC hpx hpxFlags)
And then link all the tests to hpxForTests instead of to hpx.
Petr
On Tue, 9 Oct 2018 at 09:48, Biddiscombe, John A. wrote:
> I have a problem with exported flags from a project.
>
> If I use `target_compile_options(hpx PUBLIC ${flags})` hpx is compiled
> with the flags, and all 500+ tests within the project that depend on hpx
> inherit the flags too, so they get built correctly. However, the
> `HPXTargets.cmake` file that is generated with the exported targets, also
> inherits these flags and lists them in INTERFACE_COMPILE_OPTIONS, so now
> users are complaining that flags used to compile hpx are being passed onto
> their project and some of the stuff we use like `-Werror=sign-compare`
> causes a build fail in their project. If I use `target_compile_options(hpx
> PRIVATE ${flags})` then the flags are not passed on to the user projects,
> but also not passed on to the tests either. Is there an easy way of saying,
> pass these flags to all my projects within this 'PROJECT' but don't export
> them via the PUBLIC/INTERFACE to 3rd party users?
>
> Thanks
>
> JB
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>
--
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:
https://cmake.org/mailman/listinfo/cmake
Re: [CMake] target_compile_flags and PUBLIC
Have a look at '$' and '$'
generator expressions.
Le mar. 9 oct. 2018 à 09:48, Biddiscombe, John A. a
écrit :
> I have a problem with exported flags from a project.
>
> If I use `target_compile_options(hpx PUBLIC ${flags})` hpx is compiled
> with the flags, and all 500+ tests within the project that depend on hpx
> inherit the flags too, so they get built correctly. However, the
> `HPXTargets.cmake` file that is generated with the exported targets, also
> inherits these flags and lists them in INTERFACE_COMPILE_OPTIONS, so now
> users are complaining that flags used to compile hpx are being passed onto
> their project and some of the stuff we use like `-Werror=sign-compare`
> causes a build fail in their project. If I use `target_compile_options(hpx
> PRIVATE ${flags})` then the flags are not passed on to the user projects,
> but also not passed on to the tests either. Is there an easy way of saying,
> pass these flags to all my projects within this 'PROJECT' but don't export
> them via the PUBLIC/INTERFACE to 3rd party users?
>
> Thanks
>
> JB
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>
--
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:
https://cmake.org/mailman/listinfo/cmake
[CMake] target_compile_flags and PUBLIC
I have a problem with exported flags from a project.
If I use `target_compile_options(hpx PUBLIC ${flags})` hpx is compiled with the
flags, and all 500+ tests within the project that depend on hpx inherit the
flags too, so they get built correctly. However, the `HPXTargets.cmake` file
that is generated with the exported targets, also inherits these flags and
lists them in INTERFACE_COMPILE_OPTIONS, so now users are complaining that
flags used to compile hpx are being passed onto their project and some of the
stuff we use like `-Werror=sign-compare` causes a build fail in their project.
If I use `target_compile_options(hpx PRIVATE ${flags})` then the flags are not
passed on to the user projects, but also not passed on to the tests either. Is
there an easy way of saying, pass these flags to all my projects within this
'PROJECT' but don't export them via the PUBLIC/INTERFACE to 3rd party users?
Thanks
JB
--
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:
https://cmake.org/mailman/listinfo/cmake
