Re: [cmake-developers] WG: [CMake] CMake 2.8.12.201401116 is much slower than 2.8.12.1
On 1/29/2014 8:35 AM, Dominik Bernhardt wrote: I just tested it again with the latest master from today. For my particular project the configure step with the current master takes 290s. If I only replace the UseQt4.cmake in the master with the version from 2.8.12.1 the configure time goes down to 23s!! I'm also surprised that such a tiny change results in a slowdown of more than 1000%. But at least in my setup this is the case. You might want to run with --trace and see why it is spending so much time in UseQt4. Sounds like it might be doing something you are not expecting. -Bill -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake 2.8.12.201401116 is much slower than 2.8.12.1
On 01/29/2014 08:35 AM, Dominik Bernhardt wrote: I just tested it again with the latest master from today. For my particular project the configure step with the current master takes 290s. If I only replace the UseQt4.cmake in the master with the version from 2.8.12.1 the configure time goes down to 23s!! I'm also surprised that such a tiny change results in a slowdown of more than 1000%. But at least in my setup this is the case. I explained here: http://www.cmake.org/pipermail/cmake-developers/2014-January/009487.html how the '$' in a value changes some core logic from a short-circuit to a complex evaluation. However, the question now is why does this one COMPILE_DEFINITIONS property value get evaluated so many times that it becomes so noticeable. How many directories (add_subdirectory) and targets (add_library or add_executable) does the project have? -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] RFC: add version to project() call
On 2014-01-29 09:58, Brad King wrote: I reverted the 'AddVersionToProjectCommand' topic from 'next' and replaced it with a 'project-version-variables' topic that adds a policy: Help: Format project command and variable documentation http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7dcc project: Add optional LANGUAGES keyword http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=16d040c9 project: Manage VERSION variables http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7e142c5a write_basic_package_version_file: use PROJECT_VERSION http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=41d2f2c4 The key is that project() only accepts VERSION when the policy is set to NEW. After release this will be automatic because one would need cmake_minimum_required() to specify a high enough version to understand the new project() signature and that would set the policy to NEW. Once the policy is set to NEW then we can freely clear variables when project() is not given a VERSION. Can one use project(VERSION) and later set the policy to OLD to get the old, don't-unset-the-variables behavior from that point onwards? -- Matthew -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] RFC: add version to project() call
On 01/29/2014 10:33 AM, Matthew Woehlke wrote: Can one use project(VERSION) and later set the policy to OLD to get the old, don't-unset-the-variables behavior from that point onwards? Yes. A subproject that has not been updated to understand the policy would normally run cmake_minimum_required with a version old enough to unset the policy and get the old behavior (with a warning). However, a policy is not a switch between two desirable behaviors. It should never be set to OLD explicitly in new code. The only time a policy should be set to OLD is in a maintenance branch of an existing project release just to silence the policy warning. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] WG: [CMake] CMake 2.8.12.201401116 is much slower than 2.8.12.1
On Wednesday, January 29, 2014 02:35:53 PM Dominik Bernhardt wrote:
-Urspruengliche Nachricht-
Von: Clinton Stimpson [mailto:clin...@elemtech.com]
Gesendet: Dienstag, 21. Januar 2014 16:10
An: cmake-developers@cmake.org
Cc: Bill Hoffman; Dominik Bernhardt
Betreff: Re: [cmake-developers] [CMake] CMake 2.8.12.201401116 is
much slower than 2.8.12.1
[...]
I'm surprised how this small change added a 20% slowdown.
-set_property(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS_DEBUG
QT_DEBUG)
+set_property(DIRECTORY APPEND PROPERTY COMPILE_DEFINITIONS $$NOT:
$CONFIG:Debug:QT_NO_DEBUG)
I tried this project on Windows with CMake master (my own build) and
CMake (kitware build) and CMake master was slightly faster, then
modifying UseQt.cmake made it slightly faster still.
Dominik, if you are seeing a massive slowdown, can you narrow it down?
It may not be generator expression related at all.
I just tested it again with the latest master from today. For my
particular project the configure step with the current master takes
290s. If I only replace the UseQt4.cmake in the master with the
version from 2.8.12.1 the configure time goes down to 23s!!
I'm also surprised that such a tiny change results in a slowdown of
more than 1000%. But at least in my setup this is the case.
Can you try the attached modifications to Qt4Macros.cmake to see if it helps
you? And make sure you try it with the restored UseQt4.cmake file.
Clint
diff --git a/Modules/Qt4Macros.cmake b/Modules/Qt4Macros.cmake
index fd9819f..d1aaed1 100644
--- a/Modules/Qt4Macros.cmake
+++ b/Modules/Qt4Macros.cmake
@@ -84,19 +84,19 @@ macro (QT4_GET_MOC_FLAGS _moc_flags)
foreach(_current ${_inc_DIRS})
if(${_current} MATCHES \\.framework/?$)
string(REGEX REPLACE /[^/]+\\.framework framework_path
${_current})
- set(${_moc_flags} ${${_moc_flags}} -F${framework_path})
+ list(APPEND ${_moc_flags} -F${framework_path})
else()
- set(${_moc_flags} ${${_moc_flags}} -I${_current})
+ list(APPEND ${_moc_flags} -I${_current})
endif()
endforeach()
get_directory_property(_defines COMPILE_DEFINITIONS)
foreach(_current ${_defines})
-set(${_moc_flags} ${${_moc_flags}} -D${_current})
+list(APPEND ${_moc_flags} -D${_current})
endforeach()
if(Q_WS_WIN)
-set(${_moc_flags} ${${_moc_flags}} -DWIN32)
+list(APPEND ${_moc_flags} -DWIN32)
endif()
endmacro()
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] WG: [CMake] CMake 2.8.12.201401116 is much slower than 2.8.12.1
-Urspruengliche Nachricht- Von: Clinton Stimpson [mailto:clin...@elemtech.com] Gesendet: Mittwoch, 29. Januar 2014 17:07 An: cmake-developers@cmake.org Cc: Dominik Bernhardt Betreff: Re: [cmake-developers] WG: [CMake] CMake 2.8.12.201401116 is much slower than 2.8.12.1 [...] Can you try the attached modifications to Qt4Macros.cmake to see if it helps you? And make sure you try it with the restored UseQt4.cmake file. Unfortunately it did not help. Approximately same results as before. Dominik -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] WG: [CMake] CMake 2.8.12.201401116 is much slower than 2.8.12.1
On 1/29/2014 11:54 AM, Dominik Bernhardt wrote: Unfortunately it did not help. Approximately same results as before. Have you run --trace to see why UseQt4 is being parsed so many times? -Bill -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] kwrobot changing documentation
I noticed in the git history that the kitware robot changed the documentation in the source files to something with :: characters between paragraphs. It also seemed to add them between the paragraphs of the same descriptions: # CUDA_WRAP_SRCS ( cuda_target format generated_files file0 file1 ... #[STATIC | SHARED | MODULE] [OPTIONS ...] ) # -- This is where all the magic happens. CUDA_ADD_EXECUTABLE, # CUDA_ADD_LIBRARY, CUDA_COMPILE, and CUDA_COMPILE_PTX all call this # function under the hood. # # # # :: # # Given the list of files (file0 file1 ... fileN) this macro generates # custom commands that generate either PTX or linkable objects (use PTX or # OBJ for the format argument to switch). Files that don't end with .cu # or have the HEADER_FILE_ONLY property are ignored. # # # # :: # # The arguments passed in after OPTIONS are extra command line options to # give to nvcc. You can also specify per configuration options by # specifying the name of the configuration followed by the options. General # options must preceed configuration specific options. Not all # configurations need to be specified, only the ones provided will be used. What do these :: characters do? I think they should only be between variables and not within a single variable or macro's documentation. James -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] add_custom_command changes, was [Introductions and questions]
On Jan 24, 2014, at 3:25 PM, Steve Wilson ste...@wolfram.com wrote: The first item I would like to see merged back to the project is issue 9974 in the Mantis tracker (CMake should support custom commands that can vary by configuration). I am the author of the original set of patches submitted in that report. I did not have time to follow up on that Mantis issue as responses developed, but can follow up now. In looking back through my changes for this issue and updating the changes for the current sources, I’ve realized that generator expressions in custom commands might be sufficient for my needs (my build system was initially designed in 2009 and hasn’t been significantly updated for new features such as generator expressions). However there is one bug (14353) that prevents them from being fully useful. My proposed changes for add_custom_command would be the following: add_custom_command(OUTPUT output1 [output2 ...] COMMAND command1 [ARGS] [args1...] [COMMAND command2 [ARGS] [args2...] ...] [MAIN_DEPENDENCY depend] [DEPENDS [depends...]] [IMPLICIT_DEPENDS lang1 depend1 [lang2 depend2] ...] [WORKING_DIRECTORY dir] [COMMENT comment] [VERBATIM] [APPEND] [CONFIG Debug | MinSizeRel | Release | RelWithDebInfo | ...]) add_custom_command(TARGET target PRE_BUILD | PRE_LINK | POST_BUILD COMMAND command1 [ARGS] [args1...] [COMMAND command2 [ARGS] [args2...] ...] [WORKING_DIRECTORY dir] [COMMENT comment] [VERBATIM] [CONFIG Debug | MinSizeRel | Release | RelWithDebInfo | ...]) The addition of course here is the CONFIG keyword that takes a configuration argument. When add_custom_command() has a CONFIG argument, all of the commands in the custom command only get executed if the build is configured in the requisite configuration (or is selected in an IDE configuration). Currently generator expressions in custom commands cannot work for this kind of usage because of bug 14353. In 14353 generator expressions that have a space character (i.e. more content than just one word/command) don’t parse correctly and thus make complex custom commands that vary by configuration impossible to construct. Is there a need for the add_custom_command() version with CONFIG? While the generator expressions make short add_custom_command() usages work quite nicely I could see the case where the generator expression syntax might become unwieldy for larger custom commands that have many COMMAND statements. I personally would not want to write: add_custom_command(… COMMAND $$CONFIG:…:… COMMAND $$CONFIG:…:… COMMAND $$CONFIG:…:… ... ) repeatedly, while having to embed my command inside the generator $$CONFIG:…:… syntax. My build systems have custom commands for Unix/Windows/etc… that require careful attention to make sure the commands execute correctly in the platform specific command interpreters and the $$ syntax would just be an extra confusing layer to have to maintain. Even though most usage cases would be fine with the generator expressions, I would still find the add_custom_command() with the CONFIG keyword useful for use with long custom commands. However, if everyone else thinks there is really no need for this form of add_custom_command, then I would stop working on re-integrating my changes into the source tree and work on 14353 instead. Opinions? signature.asc Description: Message signed with OpenPGP using GPGMail -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Policy CMP0043
In working with my older build system with CMake from the master branch, I quickly ran into policy CMP0043: Ignore COMPILE_DEFINITIONS_Config properties. My build system makes heavy use of the COMPILE_DEFINITIONS_Config, COMPILE_FLAGS_Config, LINK_FLAGS_Config paradigm for setting compiler/linker options.While I didn’t see a specific policy for COMPILE_FLAGS moving to COMPILE_OPTIONS, the sources seem to indicate that COMPILE_FLAGS_Config (and indeed the use of COMPILE_FLAGS) will be deprecated in favor of COMPILE_OPTIONS and the newer methods of modifying COMPILE_OPTIONS such as target_compile_options().Of course I would assume that LINK_FLAGS and LINK_FLAGS_Config would go this route as well. I noticed however that target_link_options() does not exist.Two questions: 1. Is there a plan to move LINK_FLAGS to a LINK_OPTIONS replacement and provide a target_link_options() command? (BTW, where could I find the master feature plans and timetables?) 2. If so, is someone already working on this implementation? If not, I’ve started an implementation branch of my own, but realized I probably shouldn’t walk too far down that road without getting answers for these two questions. Thanks, Steve signature.asc Description: Message signed with OpenPGP using GPGMail -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014724]: InstallRequiredSystemLibraries does not work with component-based installers
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14724 == Reported By:Craig Scott Assigned To: == Project:CMake Issue ID: 14724 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2014-01-29 19:12 EST Last Modified: 2014-01-29 19:12 EST == Summary:InstallRequiredSystemLibraries does not work with component-based installers Description: The InstallRequiredSystemLibraries CMake module includes code which invokes the install() command (see the end of InstallRequiredSystemLibraries.cmake). Unfortunately, it provides no opportunity to specify an install COMPONENT to be included in that, so when you use a component-based installer, the system runtime libraries cannot be pulled in. It is probably relatively simple to provide an additional CMake variable to optionally specify an install component and if that variable is non-empty, use that as the component name in the install() command. I'd propose something like CMAKE_INSTALL_SYSTEM_RUNTIME_COMPONENT as the variable name, but anything that is sane (and documented!) should be fine. Steps to Reproduce: Include the InstallRequiredSystemLibraries module on a platform where it makes a difference (currently only Windows with Visual Studio compilers I think). Make sure the project builds a binary linked to a runtime (eg MSVC runtime) and install that target using a COMPONENT. Then invoke the packaging as a component-based installer. == Issue History Date ModifiedUsername FieldChange == 2014-01-29 19:12 Craig ScottNew Issue == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake] Reverse logic
Re-including the list. You could also find more details reading the documentation of the if command. See http://www.cmake.org/cmake/help/git-master/command/if.html On Wed, Jan 29, 2014 at 7:40 PM, Rob McDonald rob.a.mcdon...@gmail.comwrote: Yep, that does it for me. Sneaky... Rob On Wed, Jan 29, 2014 at 4:23 PM, Jean-Christophe Fillion-Robin jchris.filli...@kitware.com wrote: Hi Rob, What about: if( NOT USE_SYSTEM_FOO) # Build my own FOO endif() Hth Jc -- +1 919 869 8849 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
