Re: [cmake-developers] [CMake] Forwarding parameters to cmake through cmake-gui
Would it makes sense to have cmake-gui behaving like ccmake ? After all there are both UI. It would accept the same set of options: -C initial-cache -D var:type=value -U globbing_expr -G generator-name -T toolset-name It would appear that ccmake is behaving incorrectly with respect to -D processing... http://public.kitware.com/Bug/view.php?id=14538 So I think avoiding the phrase like ccmake in this discussion would be a good thing. I do agree that ccmake and cmake-gui should behave the same with respect to these command line parameters. But I think ccmake is not the good example that we would want it to be... David C. -- 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] CMakeParseArguments: Do not skip empty arguments
Hello all,
Current implementation of cmake_parse_arguments skips empty arguments.
For example:
cmake_parse_arguments(OPTION SINGLE MULTI ${ARGN})
with ARGN that is set using something like:
args SINGLE more args # (args;SINGLE;;more args)
args SINGLE # (args;SINGLE;)
it will fail in 3 different ways:
1) because the foreach skips empty arguments
2) because list(APPEND list ${currentArg}) will fail to append an
empty element to the list if currentArg is an empty string.
3) because empty arguments are not passed to cmake_parse_arguments
if not quoted, i.e. if ARGN=a;;b
* ${ARGN} will pass the arguments a, b
* ${ARGN} will pass the arguments a, , b
I wrote a small patch to fix this, you can find it in the
CMakeParseArguments_EmptyArgs topic. This patch fixes the first
behaviour using foreach(IN LISTS) version, the second by enclosing
currentArg in quotes where required, and finally fixes the documentation
in order to suggest to use quoted ${ARGN} in order not to miss the
empty arguments at the end of the list.
I don't know if this is to be considered a change of behaviour though,
but I'd rather consider it a bug, and I would like to see it fixed in
the next bugfix release... what do you think?
Cheers,
Daniele
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake] Forwarding parameters to cmake through cmake-gui
+1 for Mathews solution. To bad it's just on the developers list. I will simply cite him: On 2013-11-04 15:47, David Cole wrote: * My question is still not answered completely: ** When should the new variable be added? On startup is not really ** possible because it might be the case that your src/binary directory ** is not set properly. ** So you would agree that it makes sense to do it on configure but ** only if the cache is empty? This will not allow to overwrite the ** variable via parameter but I guess that usecase is not very ** common? ** On startup is the only time it does make sense. After that, the user ** should be in charge, and the command line settings should not be ** re-applied again after a user makes an edit. You don't need the ** src/binary directories set properly necessarily in order to add a cache ** entry to the UI. * There are two mostly separate issues here. As far as the bug, the ccmake behavior is (IMO, but seems generally shared) is just wrong. physhh's questions (above) don't apply to this case because there is no concept of interactively selecting the build directory in ccmake. So fixing this is, if not easy, at least easy to understand how it should behave. As far as cmake-gui, there are no backward compatibility issues because right now it just doesn't support -D at all. It does however get more complicated... - What should happen with a -D option if there is not initially a build directory selected? - What should happen if the wrong build directory is initially selected and subsequently changed? It seems non-desirable here to forget -D (etc.) entirely at that point. * ccmake and cmake-gui *should* behave (in *my* opinion) as follows: ** - on startup, load the CMakeCache.txt values (if there are any) from the ** previous run ** - then apply the -D arguments so that any -D arguments given on the ** command line overwrite previous cache entries (just like command line ** cmake does already) ** - then put the user in charge and wait for user input * I suppose if I were writing the patch, I would have cmake-gui remember whatever -D/-U/etc. options are given and apply them to any build directory when it is selected, after loading the cache (if any). But *don't* pass them on the cmake (except inasmuch as the initial cache will contain them, modulo any changes the user made in the mean time). IOW, if I specify a -D to cmake-gui, change that value, then change to some other build directory, that -D would reset to the value from the command line. This is consistent with the current behavior that any other changes to the cache of the initial build directory are also lost. Hmm... a corner case comes to mind, however; if I configure build directory A after changing a -D value, then switch to build directory B, then back to A, I probably don't want to reapply the -D. So maybe cmake-gui would keep track of what build directories have been configured in that instance and not apply -D/etc. to them. (However, it's probably not very common for that to happen.) Make sense? -- Matthew On Tue, Nov 5, 2013 at 3:25 PM, David Cole dlrd...@aol.com wrote: My question is still not answered completely: When should the new variable be added? On startup is not really possible because it might be the case that your src/binary directory is not set properly. So you would agree that it makes sense to do it on configure but only if the cache is empty? This will not allow to overwrite the variable via parameter but I guess that usecase is not very common? On startup is the only time it does make sense. After that, the user should be in charge, and the command line settings should not be re-applied again after a user makes an edit. You don't need the src/binary directories set properly necessarily in order to add a cache entry to the UI. ... - What should happen with a -D option if there is not initially a build directory selected? It should add UI entries even though there is no build directory selected, and set them according to the -D values. Then, the -D values should be forgotten about and never applied again during that session, regardless of future user actions. Also, you could require that for -D args to work properly, the current directory *is* the binary directory at startup time (just like cmake and ccmake). If you're passing -D arguments to the gui program, then you have control over its launching point, and can set the current directory to be whatever you like. If launched without a build directory, you could choose the last known build directory (if there is one) just like cmake-gui does now. If no build directory, no -D args. - What should happen if the wrong build directory is initially selected and subsequently changed? It seems non-desirable here to forget -D (etc.) entirely at that point. No, it seems desirable to forget them at that point. They only apply to the build tree you launched it with. If you change the
[cmake-developers] Ninja pools
I merged a proposal to next which adds support for Ninja's pool:
http://martine.github.io/ninja/manual.html#ref_pool
It adds three new properties, POOLS, LINK_POOL, COMPILE_POOL:
http://www.cmake.org/cmake/help/git-next/manual/cmake-properties.7.html
With a pool it is possible to limit the number of concurrent
processes of a specific rule.
For instance if you have a project with multiple targets and
each target needs all your resources while linking (memory,
hard-disk bandwidth), it makes no sens to start multiple link
processes in parallel. To prevent this the pool feature was
introduced in ninja.
In concrete, with this patch:
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 25cd576..d257c97 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -21,6 +21,8 @@ if(CMAKE_BOOTSTRAP)
unset(CMAKE_BOOTSTRAP CACHE)
endif()
+set_property(GLOBAL PROPERTY POOLS compile=1)
+
if(${CMake_SOURCE_DIR} STREQUAL ${CMAKE_SOURCE_DIR})
diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt
index c01245c..d7c68d5 100644
--- a/Source/CMakeLists.txt
+++ b/Source/CMakeLists.txt
@@ -393,6 +393,8 @@ target_link_libraries(CMakeLib cmsys
${CMAKE_TAR_LIBRARIES} ${CMAKE_COMPRESS_LIBRARIES}
${CMAKE_CURL_LIBRARIES} )
+set_property(TARGET CMakeLib PROPERTY COMPILE_POOL compile)
+
and the current next branch, ninja builds CMakeLib single threaded,
without passing -j1 to ninja.
Current patch adds only the essentials, but maybe there are more
comfortable ways to use pools.
Peter
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake] Forwarding parameters to cmake through cmake-gui
On Tuesday 05 November 2013, David Cole wrote: My question is still not answered completely: When should the new variable be added? On startup is not really possible because it might be the case that your src/binary directory is not set properly. So you would agree that it makes sense to do it on configure but only if the cache is empty? This will not allow to overwrite the variable via parameter but I guess that usecase is not very common? On startup is the only time it does make sense. After that, the user should be in charge, and the command line settings should not be re-applied again after a user makes an edit. You don't need the src/binary directories set properly necessarily in order to add a cache entry to the UI. ... - What should happen with a -D option if there is not initially a build directory selected? It should add UI entries even though there is no build directory selected, and set them according to the -D values. Then, the -D values should be forgotten about and never applied again during that session, regardless of future user actions. Also, you could require that for -D args to work properly, the current directory *is* the binary directory at startup time (just like cmake and ccmake). If you're passing -D arguments to the gui program, then you have control over its launching point, and can set the current directory to be whatever you like. If launched without a build directory, you could choose the last known build directory (if there is one) just like cmake-gui does now. If no build directory, no -D args. I tried the following a few times in the past and noticed everytime that it does not work: $ cd src src/ $ mkdir build src/ $ cd build src/build/ $ cmake-gui -DSOME_VARIABLE=some_value .. I'd like that to work. Would it work with your proposal ? Once the cache is deleted in cmake-gui, I would expect that the values from the command line are also forgotten, also the -U values. Otherwise this cmake would remove the matching entries from every cache I load. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake] Forwarding parameters to cmake through cmake-gui
On Tuesday 05 November 2013, Jean-Christophe Fillion-Robin wrote: Would it makes sense to have cmake-gui behaving like ccmake ? After all there are both UI. It would accept the same set of options: -C initial-cache = Pre-load a script to populate the cache. -D var:type=value = Create a cmake cache entry. -U globbing_expr = Remove matching entries from CMake cache. I agree. -G generator-name = Specify a makefile generator. -T toolset-name = Specify toolset name if supported by generator. Not sure about these two. I have to select them anyway when starting configure, I don't see much value in overriding this from the command line. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMakeParseArguments: Do not skip empty arguments
On Tuesday 05 November 2013, Daniele E. Domenichelli wrote:
Hello all,
Current implementation of cmake_parse_arguments skips empty arguments.
For example:
cmake_parse_arguments(OPTION SINGLE MULTI ${ARGN})
with ARGN that is set using something like:
args SINGLE more args # (args;SINGLE;;more args)
args SINGLE # (args;SINGLE;)
it will fail in 3 different ways:
1) because the foreach skips empty arguments
2) because list(APPEND list ${currentArg}) will fail to append an
empty element to the list if currentArg is an empty string.
3) because empty arguments are not passed to cmake_parse_arguments
if not quoted, i.e. if ARGN=a;;b
* ${ARGN} will pass the arguments a, b
* ${ARGN} will pass the arguments a, , b
Not sure about the third point. It could be done intentionally that way in
order to ignore empty strings.
I wrote a small patch to fix this, you can find it in the
CMakeParseArguments_EmptyArgs topic. This patch fixes the first
behaviour using foreach(IN LISTS) version, the second by enclosing
currentArg in quotes where required, and finally fixes the documentation
in order to suggest to use quoted ${ARGN} in order not to miss the
empty arguments at the end of the list.
I don't know if this is to be considered a change of behaviour though,
but I'd rather consider it a bug, and I would like to see it fixed in
the next bugfix release... what do you think?
cmake_parse_arguments() is used in quite a few places in the meantime, so I
don't really feel good about changing its behaviour in general.
Maybe an option for the macro what it should do with empty values ?
Alex
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake] Forwarding parameters to cmake through cmake-gui
On 2013-11-05 14:36, Alexander Neundorf wrote: I tried the following a few times in the past and noticed everytime that it does not work: $ cd src src/ $ mkdir build src/ $ cd build src/build/ $ cmake-gui -DSOME_VARIABLE=some_value .. I'd like that to work. Would it work with your proposal ? Yes. Once the cache is deleted in cmake-gui, I would expect that the values from the command line are also forgotten, also the -U values. Otherwise this cmake would remove the matching entries from every cache I load. True. (But what if that's what you want?) The biggest problem is, what if you run cmake-gui without specifying a build directory? In that case, whatever comes up initially is as likely as not *not* the directory you want to apply options to. What about having an option (e.g. a combo box) when to apply command line options? - At startup (only initial / specified on command line build directory) - New projects (when no CMakeCache.txt exists yet, but also at startup) - Unconfigured projects (per my original proposal) - Always (i.e. when selecting a different build directory) The default could be 'new projects' if no build directory is specified on the command line (probably you are giving common rather than project specific options in this case), otherwise 'at startup' (more chance options are project specific). -- 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] [CMake] Forwarding parameters to cmake through cmake-gui
On 2013-11-05 14:36, Alexander Neundorf wrote: On Tuesday 05 November 2013, Jean-Christophe Fillion-Robin wrote: Would it makes sense to have cmake-gui behaving like ccmake ? After all there are both UI. It would accept the same set of options: [...] -G generator-name = Specify a makefile generator. -T toolset-name = Specify toolset name if supported by generator. Not sure about these two. I have to select them anyway when starting configure, I don't see much value in overriding this from the command line. Specifying them on the command line would allow you to skip the GUI dialog to select them. -- 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] [CMake] Forwarding parameters to cmake through cmake-gui
On Tue, Nov 5, 2013 at 8:56 PM, Matthew Woehlke matthew.woeh...@kitware.com wrote: On 2013-11-05 14:36, Alexander Neundorf wrote: I tried the following a few times in the past and noticed everytime that it does not work: $ cd src src/ $ mkdir build src/ $ cd build src/build/ $ cmake-gui -DSOME_VARIABLE=some_value .. I'd like that to work. Would it work with your proposal ? Yes. Once the cache is deleted in cmake-gui, I would expect that the values from the command line are also forgotten, also the -U values. Otherwise this cmake would remove the matching entries from every cache I load. True. (But what if that's what you want?) Could you give me a use case where u actuall don't want this? As already stated are the command line parameters the default values. If I dont' want to remove an entry by default I won't pass that parameter. If I want to remove an entry (but not by default) I will do it with the gui itself - That's what the gui is for? The biggest problem is, what if you run cmake-gui without specifying a build directory? In that case, whatever comes up initially is as likely as not *not* the directory you want to apply options to. What about having an option (e.g. a combo box) when to apply command line options? - At startup (only initial / specified on command line build directory) - New projects (when no CMakeCache.txt exists yet, but also at startup) - Unconfigured projects (per my original proposal) - Always (i.e. when selecting a different build directory) The default could be 'new projects' if no build directory is specified on the command line (probably you are giving common rather than project specific options in this case), otherwise 'at startup' (more chance options are project specific). -- 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 -- 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] Forwarding parameters to cmake through cmake-gui
On 2013-11-05 15:14, physhh . wrote: On Tue, Nov 5, 2013 at 8:56 PM, Matthew Woehlke wrote: On 2013-11-05 14:36, Alexander Neundorf wrote: Once the cache is deleted in cmake-gui, I would expect that the values from the command line are also forgotten, also the -U values. Otherwise this cmake would remove the matching entries from every cache I load. True. (But what if that's what you want?) Could you give me a use case where u actuall don't want this? As already stated are the command line parameters the default values. If I dont' want to remove an entry by default I won't pass that parameter. If I want to remove an entry (but not by default) I will do it with the gui itself - That's what the gui is for? The use case is invoking cmake-gui by hand from a command line for a specific project (i.e. specifying the build directory also on the command line). As I see it, folks that are used to cmake/ccmake tend to want cmake-gui to work more like that. Whereas folks that are used to doing everything from GUI's and hardly if ever touch a command line want it to work like we're suggesting. Both points of view are IMO valid (though I tend towards greater sympathy for the latter in this case). (Personally, I'd say I'm middle of the road; I use a CLI plenty¹ - and TBH, ccmake much more than cmake-gui - but I (try to) understand and respect the non-CLI use case.) (¹ ...though not nearly as much as some people I know. I do prefer kwin and kdevelop over ratpoison and vim/emacs, thank you ;-).) -- 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] [CMake] Forwarding parameters to cmake through cmake-gui
Wouldn't it then be possible to write a simple shell script for those people who really want that use case which calls cmake with -U and afterwards call cmake-gui? Sorry if I didn't understood it as it was ment. For me the thing is: I prefer a simple solution which allows the same stuff which is possible with cmake itself (e.g. writing custom scripts which set default entries) and not to bloat the gui with stuff which are not used very often and can be achieved already with a combination of cmake/cmake-gui On Tue, Nov 5, 2013 at 9:40 PM, Matthew Woehlke matthew.woeh...@kitware.com wrote: On 2013-11-05 15:14, physhh . wrote: On Tue, Nov 5, 2013 at 8:56 PM, Matthew Woehlke wrote: On 2013-11-05 14:36, Alexander Neundorf wrote: Once the cache is deleted in cmake-gui, I would expect that the values from the command line are also forgotten, also the -U values. Otherwise this cmake would remove the matching entries from every cache I load. True. (But what if that's what you want?) Could you give me a use case where u actuall don't want this? As already stated are the command line parameters the default values. If I dont' want to remove an entry by default I won't pass that parameter. If I want to remove an entry (but not by default) I will do it with the gui itself - That's what the gui is for? The use case is invoking cmake-gui by hand from a command line for a specific project (i.e. specifying the build directory also on the command line). As I see it, folks that are used to cmake/ccmake tend to want cmake-gui to work more like that. Whereas folks that are used to doing everything from GUI's and hardly if ever touch a command line want it to work like we're suggesting. Both points of view are IMO valid (though I tend towards greater sympathy for the latter in this case). (Personally, I'd say I'm middle of the road; I use a CLI plenty¹ - and TBH, ccmake much more than cmake-gui - but I (try to) understand and respect the non-CLI use case.) (¹ ...though not nearly as much as some people I know. I do prefer kwin and kdevelop over ratpoison and vim/emacs, thank you ;-).) -- 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 -- 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] Forwarding parameters to cmake through cmake-gui
On Tuesday 05 November 2013, Matthew Woehlke wrote: On 2013-11-05 14:36, Alexander Neundorf wrote: I tried the following a few times in the past and noticed everytime that it does not work: $ cd src src/ $ mkdir build src/ $ cd build src/build/ $ cmake-gui -DSOME_VARIABLE=some_value .. I'd like that to work. Would it work with your proposal ? Yes. Once the cache is deleted in cmake-gui, I would expect that the values from the command line are also forgotten, also the -U values. Otherwise this cmake would remove the matching entries from every cache I load. True. (But what if that's what you want?) I think I would expect -U only to work if a cache is loaded initially, i.e. if cmake-gui is started with an existing build dir. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake] Forwarding parameters to cmake through cmake-gui
As I see it, folks that are used to cmake/ccmake tend to want cmake-gui to work more like that. Whereas folks that are used to doing everything from GUI's and hardly if ever touch a command line want it to work like we're suggesting. Both points of view are IMO valid (though I tend towards greater sympathy for the latter in this case). (Personally, I'd say I'm middle of the road; I use a CLI plenty¹ - and TBH, ccmake much more than cmake-gui - but I (try to) understand and respect the non-CLI use case.) I would simply like to point out, with all due respect, that in the non-CLI use case, it is IMPOSSIBLE to pass command line parameters. Therefore, when discussing how command line parameters ought to behave, you do not have to consider the non-CLI use case. (Other than, obviously, not requiring any changes to the non-CLI use case to accommodate new command line features...) D -- 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] Forwarding parameters to cmake through cmake-gui
On Nov 5, 2013, at 6:40 PM, Matthew Woehlke matthew.woeh...@kitware.com wrote: On 2013-11-05 17:40, David Cole wrote: I would simply like to point out, with all due respect, that in the non-CLI use case, it is IMPOSSIBLE to pass command line parameters. 1. I can modify my shortcut / .desktop file (which I previously stated as a use case for the feature). 2. I can launch cmake-gui from the run / launcher dialog. In both cases, I'm not using a (full) CLI, but I can still pass command line arguments. (The latter is admittedly a little CLI-like, but its working directory is still poorly defined and probably you are not specifying a build directory in that case.) Ok, I guess I should know better than to use the word IMPOSSIBLE... Although I would call both of those (perhaps sideways) CLI usage. I think the feature should be well-defined and easy to explain before it's implemented. I will defer to the wisdom of the crowd on this, (i.e. I've said my piece and now I'll be quiet) but if it can't be explained in a short paragraph of text, I still maintain that it's overly complicated. D -- 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 0014546]: CACHE variables persist through reruns
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=14546 == Reported By:Alp Toker Assigned To: == Project:CMake Issue ID: 14546 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2013-11-06 00:33 EST Last Modified: 2013-11-06 00:33 EST == Summary:CACHE variables persist through reruns Description: Hello, We're using CMake in the LLVM/clang Open Source project and noticed that CACHE variables are getting persisted after regenerating makefiles (reference: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-October/032957.html) This means that upstream SVN changes to any CACHE variable (such as the binary version number, default bug report URL etc.) don't take effect on developers systems. The most visible result of this is that, when the project makes a new release, existing builds continue to use the old version number taken from the cache. This happens with all other CACHE variables too. Steps to Reproduce: Configure a project that has the following CACHE variable in CMakeLists.txt: set(BUG_REPORT_URL http://llvm.org/bugstypo/; CACHE STRING Default URL where bug reports are to be submitted.) Then build the project. Then modify the URL in CMakeLists.txt, changing it from http://llvm.org/bugstypo/; to http://llvm.org/bugs/; Then rebuild the project. Problem: BUG_REPORT_URL is still http://llvm.org/bugstypo/; Expected result: BUG_REPORT_URL should have been updated to http://llvm.org/bugs/; The issue has been observed with the Makefile and Ninja generator, and presumably all other generators are affected. Additional Information: I've investigated and this seems to be a bug in cmMakefile::AddCacheDefinition(), which is caching the default value for the variable even when the user hasn't overridden it on the commandline or in the CMake GUI. I'm working on a patch that teaches CMake to differentiate between the declaration, definition and default value of a CACHE variable. An additional benefit of this approach is that it adds a Reset to default option for CACHE variables in the CMake GUI. There should otherwise be no change in behaviour other than resolving the problem as described. Specifically, if the user defines the variable explicitly, the user definition will continue persist same as before. I'll upload the patch shortly. Please let me know if you're already aware of / working on an alternative solution to this issue. == Issue History Date ModifiedUsername FieldChange == 2013-11-06 00:33 Alp Toker New 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
[CMake] Custom Toolchain CMAKE_MAKE_PROGRAM
Hi, I'm trying to use cmake with a bare metal coldfire project. The cross compiler (m68k-elf-gcc) running in msys (Win7x64) is working fine. Now I want to use the CMake GUI (2.8.12) for the project. I've started with a simple CMakeLists.txt and a custom toolchain file that starts with these lines: include(CMakeForceCompiler) set(CMAKE_SYSTEM_NAME Generic) set(CMAKE_MAKE_PROGRAM c:/devel/msys-gcc-m68k-elf/bin/make) In the CMake GUI, after clicking Configure I chose the MSYS Makefiles Generator with the Specify toolchain file for cross-compiling option, where I point cmake to the above file. CMake then throws lots of errors, of which the first one is: CMake Error: CMake was unable to find a build program corresponding to MSYS Makefiles. CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool. I did set CMAKE_MAKE_PROGRAM in the toolchain file, I tried setting it in the CMakeLists.txt as well. Anyway I'm getting the error. I'm new to CMake, so I guess it's a misunderstanding on my side of how CMake works. What's going on here? Regards, Michael -- Michael Weise michael.we...@ek-team.de -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Custom Toolchain CMAKE_MAKE_PROGRAM
On Tue, 5 Nov 2013 10:49:05 +0100 Michael Weise michael.we...@ek-team.de wrote: I'm new to CMake, so I guess it's a misunderstanding on my side of how CMake works. What's going on here? I found the answer myself here: http://stackoverflow.com/questions/5006286/cmake-set-doesnt-work-on-same-variable-after-find-path-was-called This is a common misconception about set and CMake cache variables. set ... sets a local override value ... but it has no effect on the cache variable of the same name. Therefore, it is not visible in the cmake-gui or ccmake cache editing programs. Regards Michael -- 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://www.cmake.org/mailman/listinfo/cmake
[CMake] Install multiple components using CPack
Hi all, I have a CMake project for which I want to generate a RPM and/or ZIP file. But instead of including all components/groups I want to control this. I do know I can create a CPack configuration file to create a package for 1 component using CPACK_INSTALL_CMAKE_PROJECTS, how can I do this for a component_group? For example, I have a component group called bundles, and also several components (eg a and b). Both a and b are added to the group bundles. How can I now create one CPack configuration so that I have one package containing all bundles? -- Thanks in advance, Alexander Broekhuis -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] Forwarding parameters to cmake through cmake-gui
Would it makes sense to have cmake-gui behaving like ccmake ? After all there are both UI. It would accept the same set of options: -C initial-cache -D var:type=value -U globbing_expr -G generator-name -T toolset-name It would appear that ccmake is behaving incorrectly with respect to -D processing... http://public.kitware.com/Bug/view.php?id=14538 So I think avoiding the phrase like ccmake in this discussion would be a good thing. I do agree that ccmake and cmake-gui should behave the same with respect to these command line parameters. But I think ccmake is not the good example that we would want it to be... David C. -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] Forwarding parameters to cmake through cmake-gui
My question is still not answered completely: When should the new variable be added? On startup is not really possible because it might be the case that your src/binary directory is not set properly. So you would agree that it makes sense to do it on configure but only if the cache is empty? This will not allow to overwrite the variable via parameter but I guess that usecase is not very common? On startup is the only time it does make sense. After that, the user should be in charge, and the command line settings should not be re-applied again after a user makes an edit. You don't need the src/binary directories set properly necessarily in order to add a cache entry to the UI. ... - What should happen with a -D option if there is not initially a build directory selected? It should add UI entries even though there is no build directory selected, and set them according to the -D values. Then, the -D values should be forgotten about and never applied again during that session, regardless of future user actions. Also, you could require that for -D args to work properly, the current directory *is* the binary directory at startup time (just like cmake and ccmake). If you're passing -D arguments to the gui program, then you have control over its launching point, and can set the current directory to be whatever you like. If launched without a build directory, you could choose the last known build directory (if there is one) just like cmake-gui does now. If no build directory, no -D args. - What should happen if the wrong build directory is initially selected and subsequently changed? It seems non-desirable here to forget -D (etc.) entirely at that point. No, it seems desirable to forget them at that point. They only apply to the build tree you launched it with. If you change the build directory, they do not apply. I suppose if I were writing the patch, I would have cmake-gui remember whatever -D/-U/etc. options are given and apply them to any build directory when it is selected, after loading the cache (if any). But *don't* pass them on the cmake (except inasmuch as the initial cache will contain them, modulo any changes the user made in the mean time). IOW, if I specify a -D to cmake-gui, change that value, then change to some other build directory, that -D would reset to the value from the command line. This is consistent with the current behavior that any other changes to the cache of the initial build directory are also lost. Hmm... a corner case comes to mind, however; if I configure build directory A after changing a -D value, then switch to build directory B, then back to A, I probably don't want to reapply the -D. So maybe cmake-gui would keep track of what build directories have been configured in that instance and not apply -D/etc. to them. (However, it's probably not very common for that to happen.) Make sense? Not really -- I think you're vastly over complicating the solution to a very simple problem. D -- 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://www.cmake.org/mailman/listinfo/cmake
[CMake] INSTALL_COMMAND for ExternalProject not overriding the install step
Hello.
I'm using ExternalProject to build a CMakeLists.txt in a subdirectory.
This subdirectory is used by other applications, files are included
from that subdirectory directly, but that subdirectory doesn't install
anything but does contain the unit tests for the files in that
directory and I'd still like 'make test' to work properly from my top
level CMakeLists.txt that is including this ExternalProject.
So, I'm trying to override the INSTALL_COMMAND but it doesn't appear
to be working correctly.
#add_subdirectory(shared_cpp)
ExternalProject_Add(
shared_cpp
SOURCE_DIR ${CMAKE_SOURCE_DIR}/shared_cpp
CMAKE_ARGS -DCMAKE_INSTALL_PREFIX:PATH=${CMAKE_INSTALL_PREFIX}
-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
TEST_COMMAND make test
INSTALL_COMMMAND
)
I'm still seeing cmake calling 'make install' and this causes a build failure:
make[2]: Entering directory `/home/cmorgan/projects/external/build'
/usr/bin/cmake -E cmake_progress_report
/home/cmorgan/projects/external/build/CMakeFiles 18
[ 39%] Performing install step for 'shared_cpp'
cd /home/cmorgan/projects/external/build/shared_cpp-prefix/src/shared_cpp-build
make install
make[3]: Entering directory
`/home/cmorgan/projects/external/build/shared_cpp-prefix/src/shared_cpp-build'
make[3]: *** No rule to make target `install'. Stop.
make[3]: Leaving directory
`/home/cmorgan/projects/external/build/shared_cpp-prefix/src/shared_cpp-build'
make[2]: *** [shared_cpp-prefix/src/shared_cpp-stamp/shared_cpp-install] Error 2
make[2]: Leaving directory `/home/cmorgan/projects/external/build'
make[1]: *** [CMakeFiles/shared_cpp.dir/all] Error 2
make[1]: Leaving directory `/home/cmorgan/projects/external/build'
make: *** [all] Error 2
[cmorgan@localhost build]$
Any ideas how I can fix this?
It may be that I've got something structurally wrong with the project,
for instance, because the shared_cpp/ CMakeLists.txt isn't installing
anything, so I'd welcome suggestions. The files in this directory are
used by several different applications (and the folder is itself a git
submodule). Should I be making this into a library?? I haven't been
able to find good cmake examples for large multi-executable projects
and I didn't really want to have separate git repositories for each of
our small executables that contained their own submodules of
shared_cpp, for instance.
Chris
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] INSTALL_COMMAND for ExternalProject not overriding the install step
INSTALL_COMMMAND - INSTALL_COMMAND (with only 2 'M') ?
On 11/05/2013 04:16 PM, Chris Morgan wrote:
Hello.
I'm using ExternalProject to build a CMakeLists.txt in a subdirectory.
This subdirectory is used by other applications, files are included
from that subdirectory directly, but that subdirectory doesn't install
anything but does contain the unit tests for the files in that
directory and I'd still like 'make test' to work properly from my top
level CMakeLists.txt that is including this ExternalProject.
So, I'm trying to override the INSTALL_COMMAND but it doesn't appear
to be working correctly.
#add_subdirectory(shared_cpp)
ExternalProject_Add(
shared_cpp
SOURCE_DIR ${CMAKE_SOURCE_DIR}/shared_cpp
CMAKE_ARGS -DCMAKE_INSTALL_PREFIX:PATH=${CMAKE_INSTALL_PREFIX}
-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
TEST_COMMAND make test
INSTALL_COMMMAND
)
I'm still seeing cmake calling 'make install' and this causes a build failure:
make[2]: Entering directory `/home/cmorgan/projects/external/build'
/usr/bin/cmake -E cmake_progress_report
/home/cmorgan/projects/external/build/CMakeFiles 18
[ 39%] Performing install step for 'shared_cpp'
cd
/home/cmorgan/projects/external/build/shared_cpp-prefix/src/shared_cpp-build
make install
make[3]: Entering directory
`/home/cmorgan/projects/external/build/shared_cpp-prefix/src/shared_cpp-build'
make[3]: *** No rule to make target `install'. Stop.
make[3]: Leaving directory
`/home/cmorgan/projects/external/build/shared_cpp-prefix/src/shared_cpp-build'
make[2]: *** [shared_cpp-prefix/src/shared_cpp-stamp/shared_cpp-install]
Error 2
make[2]: Leaving directory `/home/cmorgan/projects/external/build'
make[1]: *** [CMakeFiles/shared_cpp.dir/all] Error 2
make[1]: Leaving directory `/home/cmorgan/projects/external/build'
make: *** [all] Error 2
[cmorgan@localhost build]$
Any ideas how I can fix this?
It may be that I've got something structurally wrong with the project,
for instance, because the shared_cpp/ CMakeLists.txt isn't installing
anything, so I'd welcome suggestions. The files in this directory are
used by several different applications (and the folder is itself a git
submodule). Should I be making this into a library?? I haven't been
able to find good cmake examples for large multi-executable projects
and I didn't really want to have separate git repositories for each of
our small executables that contained their own submodules of
shared_cpp, for instance.
Chris
--
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://www.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:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] INSTALL_COMMAND for ExternalProject not overriding the install step
Doh. I guess I assumed that would have been kicked out earlier when I
ran 'cmake ../.
Thank you, that works now. Sorry for the noise.
Chris
On Tue, Nov 5, 2013 at 10:20 AM, Julien Malik julien.ma...@c-s.fr wrote:
INSTALL_COMMMAND - INSTALL_COMMAND (with only 2 'M') ?
On 11/05/2013 04:16 PM, Chris Morgan wrote:
Hello.
I'm using ExternalProject to build a CMakeLists.txt in a subdirectory.
This subdirectory is used by other applications, files are included
from that subdirectory directly, but that subdirectory doesn't install
anything but does contain the unit tests for the files in that
directory and I'd still like 'make test' to work properly from my top
level CMakeLists.txt that is including this ExternalProject.
So, I'm trying to override the INSTALL_COMMAND but it doesn't appear
to be working correctly.
#add_subdirectory(shared_cpp)
ExternalProject_Add(
shared_cpp
SOURCE_DIR ${CMAKE_SOURCE_DIR}/shared_cpp
CMAKE_ARGS -DCMAKE_INSTALL_PREFIX:PATH=${CMAKE_INSTALL_PREFIX}
-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
TEST_COMMAND make test
INSTALL_COMMMAND
)
I'm still seeing cmake calling 'make install' and this causes a build
failure:
make[2]: Entering directory `/home/cmorgan/projects/external/build'
/usr/bin/cmake -E cmake_progress_report
/home/cmorgan/projects/external/build/CMakeFiles 18
[ 39%] Performing install step for 'shared_cpp'
cd
/home/cmorgan/projects/external/build/shared_cpp-prefix/src/shared_cpp-build
make install
make[3]: Entering directory
`/home/cmorgan/projects/external/build/shared_cpp-prefix/src/shared_cpp-build'
make[3]: *** No rule to make target `install'. Stop.
make[3]: Leaving directory
`/home/cmorgan/projects/external/build/shared_cpp-prefix/src/shared_cpp-build'
make[2]: *** [shared_cpp-prefix/src/shared_cpp-stamp/shared_cpp-install]
Error 2
make[2]: Leaving directory `/home/cmorgan/projects/external/build'
make[1]: *** [CMakeFiles/shared_cpp.dir/all] Error 2
make[1]: Leaving directory `/home/cmorgan/projects/external/build'
make: *** [all] Error 2
[cmorgan@localhost build]$
Any ideas how I can fix this?
It may be that I've got something structurally wrong with the project,
for instance, because the shared_cpp/ CMakeLists.txt isn't installing
anything, so I'd welcome suggestions. The files in this directory are
used by several different applications (and the folder is itself a git
submodule). Should I be making this into a library?? I haven't been
able to find good cmake examples for large multi-executable projects
and I didn't really want to have separate git repositories for each of
our small executables that contained their own submodules of
shared_cpp, for instance.
Chris
--
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://www.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:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] spoof Not Run dashboard status
On 11/04/2013 10:49 PM, Rolf Eike Beer wrote: Am Montag, 4. November 2013, 16:09:04 schrieb burlen: Can a test return a value to indicate that it could not be run? http://cmake.org/Bug/view.php?id=8466 Thanks for pointing this out, I think that would be a very useful feature. -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] Forwarding parameters to cmake through cmake-gui
+1 for Mathews solution. To bad it's just on the developers list. I will simply cite him: On 2013-11-04 15:47, David Cole wrote: * My question is still not answered completely: ** When should the new variable be added? On startup is not really ** possible because it might be the case that your src/binary directory ** is not set properly. ** So you would agree that it makes sense to do it on configure but ** only if the cache is empty? This will not allow to overwrite the ** variable via parameter but I guess that usecase is not very ** common? ** On startup is the only time it does make sense. After that, the user ** should be in charge, and the command line settings should not be ** re-applied again after a user makes an edit. You don't need the ** src/binary directories set properly necessarily in order to add a cache ** entry to the UI. * There are two mostly separate issues here. As far as the bug, the ccmake behavior is (IMO, but seems generally shared) is just wrong. physhh's questions (above) don't apply to this case because there is no concept of interactively selecting the build directory in ccmake. So fixing this is, if not easy, at least easy to understand how it should behave. As far as cmake-gui, there are no backward compatibility issues because right now it just doesn't support -D at all. It does however get more complicated... - What should happen with a -D option if there is not initially a build directory selected? - What should happen if the wrong build directory is initially selected and subsequently changed? It seems non-desirable here to forget -D (etc.) entirely at that point. * ccmake and cmake-gui *should* behave (in *my* opinion) as follows: ** - on startup, load the CMakeCache.txt values (if there are any) from the ** previous run ** - then apply the -D arguments so that any -D arguments given on the ** command line overwrite previous cache entries (just like command line ** cmake does already) ** - then put the user in charge and wait for user input * I suppose if I were writing the patch, I would have cmake-gui remember whatever -D/-U/etc. options are given and apply them to any build directory when it is selected, after loading the cache (if any). But *don't* pass them on the cmake (except inasmuch as the initial cache will contain them, modulo any changes the user made in the mean time). IOW, if I specify a -D to cmake-gui, change that value, then change to some other build directory, that -D would reset to the value from the command line. This is consistent with the current behavior that any other changes to the cache of the initial build directory are also lost. Hmm... a corner case comes to mind, however; if I configure build directory A after changing a -D value, then switch to build directory B, then back to A, I probably don't want to reapply the -D. So maybe cmake-gui would keep track of what build directories have been configured in that instance and not apply -D/etc. to them. (However, it's probably not very common for that to happen.) Make sense? -- Matthew On Tue, Nov 5, 2013 at 3:25 PM, David Cole dlrd...@aol.com wrote: My question is still not answered completely: When should the new variable be added? On startup is not really possible because it might be the case that your src/binary directory is not set properly. So you would agree that it makes sense to do it on configure but only if the cache is empty? This will not allow to overwrite the variable via parameter but I guess that usecase is not very common? On startup is the only time it does make sense. After that, the user should be in charge, and the command line settings should not be re-applied again after a user makes an edit. You don't need the src/binary directories set properly necessarily in order to add a cache entry to the UI. ... - What should happen with a -D option if there is not initially a build directory selected? It should add UI entries even though there is no build directory selected, and set them according to the -D values. Then, the -D values should be forgotten about and never applied again during that session, regardless of future user actions. Also, you could require that for -D args to work properly, the current directory *is* the binary directory at startup time (just like cmake and ccmake). If you're passing -D arguments to the gui program, then you have control over its launching point, and can set the current directory to be whatever you like. If launched without a build directory, you could choose the last known build directory (if there is one) just like cmake-gui does now. If no build directory, no -D args. - What should happen if the wrong build directory is initially selected and subsequently changed? It seems non-desirable here to forget -D (etc.) entirely at that point. No, it seems desirable to forget them at that point. They only apply to the build tree you launched it with. If you change the
Re: [CMake] [cmake-developers] Forwarding parameters to cmake through cmake-gui
On 2013-11-05 09:25, David Cole wrote:
Matthew Woehlke wrote:
- What should happen with a -D option if there is not initially a
build directory selected?
It should add UI entries even though there is no build directory
selected, and set them according to the -D values. Then, the -D values
should be forgotten about and never applied again during that session,
regardless of future user actions.
Also, you could require that for -D args to work properly, the current
directory *is* the binary directory at startup time (just like cmake and
ccmake). If you're passing -D arguments to the gui program, then you
have control over its launching point, and can set the current directory
to be whatever you like.
If launched without a build directory, you could choose the last known
build directory (if there is one) just like cmake-gui does now.
If no build directory, no -D args.
[...]
I think you're vastly over complicating the solution to a very simple
problem.
If you read physsh's question that lead to this:
When should the new variable be added? On startup is not really
possible because it might be the case that your src/binary directory
is not set properly.
...it seems very explicit that your proposal is inadequate for his use case.
Besides, I don't think the parallel holds: cmake-gui != ccmake.
In ccmake, there is no concept of choosing / changing the build
directory - one *must* run it with $PWD == ${CMAKE_BINARY_DIR} - so it
makes sense to only apply -D/etc. to the initial build directory.
This is very much not the case with cmake-gui; it might be launched from
a desktop / launcher menu shortcut where all bets as to $PWD are off,
and anyway it may not even start with $PWD as the build directory.
The ability to change the build directory after launching, which is
unique to cmake-gui, is IMHO very much worth handling -D/etc. options
differently for that reason.
Again, looking at physsh's comments, I think we should be considering
the case of someone that wants to always pass the same -D/etc. arguments
'by default'. One might conceivably (expect to be able to) do this by
modifying the cmake-gui shortcut to include the desired options. For
that to work, cmake-gui would need to apply the options to any
newly-configured project, even if it wasn't the initially selected
project. (For that matter, one might conceivably want to configure
several projects, or at least several build directories, in one
'session', with the options applied to all of them.) I think this is a
very reasonable use case that should be supported, and I tried to
address that in my proposal.
--
Matthew
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] Forwarding parameters to cmake through cmake-gui
On Tue, Nov 5, 2013 at 8:56 PM, Matthew Woehlke matthew.woeh...@kitware.com wrote: On 2013-11-05 14:36, Alexander Neundorf wrote: I tried the following a few times in the past and noticed everytime that it does not work: $ cd src src/ $ mkdir build src/ $ cd build src/build/ $ cmake-gui -DSOME_VARIABLE=some_value .. I'd like that to work. Would it work with your proposal ? Yes. Once the cache is deleted in cmake-gui, I would expect that the values from the command line are also forgotten, also the -U values. Otherwise this cmake would remove the matching entries from every cache I load. True. (But what if that's what you want?) Could you give me a use case where u actuall don't want this? As already stated are the command line parameters the default values. If I dont' want to remove an entry by default I won't pass that parameter. If I want to remove an entry (but not by default) I will do it with the gui itself - That's what the gui is for? The biggest problem is, what if you run cmake-gui without specifying a build directory? In that case, whatever comes up initially is as likely as not *not* the directory you want to apply options to. What about having an option (e.g. a combo box) when to apply command line options? - At startup (only initial / specified on command line build directory) - New projects (when no CMakeCache.txt exists yet, but also at startup) - Unconfigured projects (per my original proposal) - Always (i.e. when selecting a different build directory) The default could be 'new projects' if no build directory is specified on the command line (probably you are giving common rather than project specific options in this case), otherwise 'at startup' (more chance options are project specific). -- 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 -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] Forwarding parameters to cmake through cmake-gui
Wouldn't it then be possible to write a simple shell script for those people who really want that use case which calls cmake with -U and afterwards call cmake-gui? Sorry if I didn't understood it as it was ment. For me the thing is: I prefer a simple solution which allows the same stuff which is possible with cmake itself (e.g. writing custom scripts which set default entries) and not to bloat the gui with stuff which are not used very often and can be achieved already with a combination of cmake/cmake-gui On Tue, Nov 5, 2013 at 9:40 PM, Matthew Woehlke matthew.woeh...@kitware.com wrote: On 2013-11-05 15:14, physhh . wrote: On Tue, Nov 5, 2013 at 8:56 PM, Matthew Woehlke wrote: On 2013-11-05 14:36, Alexander Neundorf wrote: Once the cache is deleted in cmake-gui, I would expect that the values from the command line are also forgotten, also the -U values. Otherwise this cmake would remove the matching entries from every cache I load. True. (But what if that's what you want?) Could you give me a use case where u actuall don't want this? As already stated are the command line parameters the default values. If I dont' want to remove an entry by default I won't pass that parameter. If I want to remove an entry (but not by default) I will do it with the gui itself - That's what the gui is for? The use case is invoking cmake-gui by hand from a command line for a specific project (i.e. specifying the build directory also on the command line). As I see it, folks that are used to cmake/ccmake tend to want cmake-gui to work more like that. Whereas folks that are used to doing everything from GUI's and hardly if ever touch a command line want it to work like we're suggesting. Both points of view are IMO valid (though I tend towards greater sympathy for the latter in this case). (Personally, I'd say I'm middle of the road; I use a CLI plenty¹ - and TBH, ccmake much more than cmake-gui - but I (try to) understand and respect the non-CLI use case.) (¹ ...though not nearly as much as some people I know. I do prefer kwin and kdevelop over ratpoison and vim/emacs, thank you ;-).) -- 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 -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] Forwarding parameters to cmake through cmake-gui
As I see it, folks that are used to cmake/ccmake tend to want cmake-gui to work more like that. Whereas folks that are used to doing everything from GUI's and hardly if ever touch a command line want it to work like we're suggesting. Both points of view are IMO valid (though I tend towards greater sympathy for the latter in this case). (Personally, I'd say I'm middle of the road; I use a CLI plenty¹ - and TBH, ccmake much more than cmake-gui - but I (try to) understand and respect the non-CLI use case.) I would simply like to point out, with all due respect, that in the non-CLI use case, it is IMPOSSIBLE to pass command line parameters. Therefore, when discussing how command line parameters ought to behave, you do not have to consider the non-CLI use case. (Other than, obviously, not requiring any changes to the non-CLI use case to accommodate new command line features...) D -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] Forwarding parameters to cmake through cmake-gui
On 2013-11-05 17:40, David Cole wrote: I would simply like to point out, with all due respect, that in the non-CLI use case, it is IMPOSSIBLE to pass command line parameters. 1. I can modify my shortcut / .desktop file (which I previously stated as a use case for the feature). 2. I can launch cmake-gui from the run / launcher dialog. In both cases, I'm not using a (full) CLI, but I can still pass command line arguments. (The latter is admittedly a little CLI-like, but its working directory is still poorly defined and probably you are not specifying a build directory in that case.) -- Matthew -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] Forwarding parameters to cmake through cmake-gui
On Nov 5, 2013, at 6:40 PM, Matthew Woehlke matthew.woeh...@kitware.com wrote: On 2013-11-05 17:40, David Cole wrote: I would simply like to point out, with all due respect, that in the non-CLI use case, it is IMPOSSIBLE to pass command line parameters. 1. I can modify my shortcut / .desktop file (which I previously stated as a use case for the feature). 2. I can launch cmake-gui from the run / launcher dialog. In both cases, I'm not using a (full) CLI, but I can still pass command line arguments. (The latter is admittedly a little CLI-like, but its working directory is still poorly defined and probably you are not specifying a build directory in that case.) Ok, I guess I should know better than to use the word IMPOSSIBLE... Although I would call both of those (perhaps sideways) CLI usage. I think the feature should be well-defined and easy to explain before it's implemented. I will defer to the wisdom of the crowd on this, (i.e. I've said my piece and now I'll be quiet) but if it can't be explained in a short paragraph of text, I still maintain that it's overly complicated. D -- 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://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v2.8.12-4870-gcd2e22d
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, next has been updated via cd2e22d33985b4db2aee112473ca1f86575884a6 (commit) via 7b29f18472faea8300b92463cc4f046f71d475e3 (commit) from 14e747219e33d8ce8e4e344b62a21084ffcf20b9 (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 - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cd2e22d33985b4db2aee112473ca1f86575884a6 commit cd2e22d33985b4db2aee112473ca1f86575884a6 Merge: 14e7472 7b29f18 Author: Peter Kuemmel syntheti...@gmx.net AuthorDate: Tue Nov 5 04:35:32 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Nov 5 04:35:32 2013 -0500 Merge topic 'ninja-edit-cache' into next 7b29f18 Revert Ninja: run cmake-gui for target edit_cache http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7b29f18472faea8300b92463cc4f046f71d475e3 commit 7b29f18472faea8300b92463cc4f046f71d475e3 Author: Peter Kümmel syntheti...@gmx.net AuthorDate: Tue Nov 5 10:34:23 2013 +0100 Commit: Peter Kümmel syntheti...@gmx.net CommitDate: Tue Nov 5 10:34:23 2013 +0100 Revert Ninja: run cmake-gui for target edit_cache This reverts commit 4dc41c1865c74bd0bc191ab07488c5fac479802c. diff --git a/Modules/CMakeGenericSystem.cmake b/Modules/CMakeGenericSystem.cmake index a7e22fc..8a14aea 100644 --- a/Modules/CMakeGenericSystem.cmake +++ b/Modules/CMakeGenericSystem.cmake @@ -65,7 +65,6 @@ if(CMAKE_GENERATOR MATCHES Ninja) Enable/Disable output of compile commands during generation. ) mark_as_advanced(CMAKE_EXPORT_COMPILE_COMMANDS) - set(CMAKE_EDIT_COMMAND cmake-gui CACHE STRING use cmake-gui for target edit_cache FORCE) endif() # GetDefaultWindowsPrefixBase diff --git a/Source/cmGlobalGenerator.cxx b/Source/cmGlobalGenerator.cxx index f626232..4fe5033 100644 --- a/Source/cmGlobalGenerator.cxx +++ b/Source/cmGlobalGenerator.cxx @@ -2152,7 +2152,7 @@ void cmGlobalGenerator::CreateDefaultGlobalTargets(cmTargets* targets) cpackCommandLines.push_back(singleLine); (*targets)[editCacheTargetName] = this-CreateGlobalTarget( - editCacheTargetName, Running cmake-gui ..., + editCacheTargetName, Running CMake cache editor..., cpackCommandLines, depends, 0); } else --- Summary of changes: Modules/CMakeGenericSystem.cmake |1 - Source/cmGlobalGenerator.cxx |2 +- 2 files changed, 1 insertions(+), 2 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.12-4873-g38140e3
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, next has been updated via 38140e304a3720d22184b0020e117df48575e867 (commit) via 47694c40e34bb7ee3e4edbeeeb264189f5e4d4d0 (commit) via f6f7531353a7154e1409ea7de72e79dd45c29366 (commit) from cd2e22d33985b4db2aee112473ca1f86575884a6 (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 - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=38140e304a3720d22184b0020e117df48575e867 commit 38140e304a3720d22184b0020e117df48575e867 Merge: cd2e22d 47694c4 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Nov 5 07:27:07 2013 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Tue Nov 5 07:27:07 2013 -0500 Merge branch 'master' into next --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.12-4877-g15d47f3
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, next has been updated
via 15d47f30f7db309ea6c92d9c5d954a6d5ee48f28 (commit)
via 132c40a8a89f701bc4cf4de8a716b5d02233d151 (commit)
via cc52b7d5f950a942f5477a7aaa86fb86e0cc37fe (commit)
via 9ef66f2b0fc86e1a4c2ae532cbb32db137ef5ffe (commit)
from 38140e304a3720d22184b0020e117df48575e867 (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 -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=15d47f30f7db309ea6c92d9c5d954a6d5ee48f28
commit 15d47f30f7db309ea6c92d9c5d954a6d5ee48f28
Merge: 38140e3 132c40a
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Nov 5 07:44:08 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Nov 5 07:44:08 2013 -0500
Merge topic 'cmake-E-autogen-crash' into next
132c40a cmake: Validate -E cmake_autogen argument count (#14545)
cc52b7d Merge branch 'cmake-E-automoc-crash' into cmake-E-autogen-crash
9ef66f2 cmake: Validate -E cmake_automoc argument count (#14545)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=132c40a8a89f701bc4cf4de8a716b5d02233d151
commit 132c40a8a89f701bc4cf4de8a716b5d02233d151
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Nov 5 07:39:45 2013 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Tue Nov 5 07:39:45 2013 -0500
cmake: Validate -E cmake_autogen argument count (#14545)
Do not access an argument index not known to exist.
Port the change from commit 9ef66f2b (cmake: Validate -E cmake_automoc
argument count, 2013-11-05) to the new location of the code.
diff --git a/Source/cmcmd.cxx b/Source/cmcmd.cxx
index 26251b3..d4f464c 100644
--- a/Source/cmcmd.cxx
+++ b/Source/cmcmd.cxx
@@ -632,7 +632,7 @@ int cmcmd::ExecuteCMakeCommand(std::vectorstd::string
args)
{
return cmcmd::ExecuteEchoColor(args);
}
-else if (args[1] == cmake_autogen)
+else if (args[1] == cmake_autogen args.size() = 4)
{
cmQtAutoGenerators autogen;
const char *config = args[3].empty() ? 0 : args[3].c_str();
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cc52b7d5f950a942f5477a7aaa86fb86e0cc37fe
commit cc52b7d5f950a942f5477a7aaa86fb86e0cc37fe
Merge: 47694c4 9ef66f2
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Nov 5 07:38:51 2013 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Tue Nov 5 07:38:51 2013 -0500
Merge branch 'cmake-E-automoc-crash' into cmake-E-autogen-crash
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9ef66f2b0fc86e1a4c2ae532cbb32db137ef5ffe
commit 9ef66f2b0fc86e1a4c2ae532cbb32db137ef5ffe
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Nov 5 07:37:23 2013 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Tue Nov 5 07:37:23 2013 -0500
cmake: Validate -E cmake_automoc argument count (#14545)
Do not access an argument index not known to exist.
diff --git a/Source/cmake.cxx b/Source/cmake.cxx
index 290aff0..14ddc1b 100644
--- a/Source/cmake.cxx
+++ b/Source/cmake.cxx
@@ -1734,7 +1734,7 @@ int cmake::ExecuteCMakeCommand(std::vectorstd::string
args)
{
return cmake::ExecuteEchoColor(args);
}
-else if (args[1] == cmake_automoc)
+else if (args[1] == cmake_automoc args.size() = 4)
{
cmQtAutomoc automoc;
const char *config = args[3].empty() ? 0 : args[3].c_str();
---
Summary of changes:
Source/cmcmd.cxx |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.12-626-gd944167
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 d94416725e6a54acaee8c692ef512ed50ee8cf29 (commit) via cde56c1223dd50d57757f03575e5e642925059f3 (commit) from f506a2efbea1f7141e6adff199f1371def139d7a (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 - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d94416725e6a54acaee8c692ef512ed50ee8cf29 commit d94416725e6a54acaee8c692ef512ed50ee8cf29 Merge: f506a2e cde56c1 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Nov 5 08:16:51 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Nov 5 08:16:51 2013 -0500 Merge topic 'FindJNI-biarch' cde56c1 FindJNI: Support biarch installations (#14541) --- Summary of changes: Modules/FindJNI.cmake |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.12-628-g46316a0
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 46316a056971084c5d3534796b4c521bf1415f08 (commit) via a06debcde91866c005e88cb9d805a3351859aeef (commit) from d94416725e6a54acaee8c692ef512ed50ee8cf29 (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 - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=46316a056971084c5d3534796b4c521bf1415f08 commit 46316a056971084c5d3534796b4c521bf1415f08 Merge: d944167 a06debc Author: Brad King brad.k...@kitware.com AuthorDate: Tue Nov 5 08:16:57 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Nov 5 08:16:57 2013 -0500 Merge topic 'FindPHP4-no-cache-output' a06debc FindPHP4: Drop extra content from reported PHP4_INCLUDE_PATH (#14540) --- Summary of changes: Modules/FindPHP4.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.12-630-g3e2eacb
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 3e2eacb638b5e3b19c58b9c87c96517b33bcb3df (commit) via d1e8a0240b6218628af0992c8cc3e89d7609a311 (commit) from 46316a056971084c5d3534796b4c521bf1415f08 (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 - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3e2eacb638b5e3b19c58b9c87c96517b33bcb3df commit 3e2eacb638b5e3b19c58b9c87c96517b33bcb3df Merge: 46316a0 d1e8a02 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Nov 5 08:17:01 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Nov 5 08:17:01 2013 -0500 Merge topic 'doc-tool-usage' d1e8a02 Help: Refine manual/*.1.rst usage summaries --- Summary of changes: Help/manual/ccmake.1.rst|8 +--- Help/manual/cmake-gui.1.rst | 10 ++ Help/manual/cmake.1.rst | 12 +--- Help/manual/cpack.1.rst |6 -- Help/manual/ctest.1.rst |6 -- 5 files changed, 28 insertions(+), 14 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.12-4885-gd294b81
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, next has been updated via d294b815de338f40f78d9a531c5e482e663e4e20 (commit) via 4ab88500ae3ac3b0be9e8be4df0d00f69efd9ff8 (commit) via 93fe461e6c2ec650a2652367509cede78cf01455 (commit) via 3e2eacb638b5e3b19c58b9c87c96517b33bcb3df (commit) via 46316a056971084c5d3534796b4c521bf1415f08 (commit) via d94416725e6a54acaee8c692ef512ed50ee8cf29 (commit) via f506a2efbea1f7141e6adff199f1371def139d7a (commit) via 7ccb8fafdb8982818e55d6f8c57b882af444c52f (commit) from 15d47f30f7db309ea6c92d9c5d954a6d5ee48f28 (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 - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d294b815de338f40f78d9a531c5e482e663e4e20 commit d294b815de338f40f78d9a531c5e482e663e4e20 Merge: 15d47f3 4ab8850 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Nov 5 08:17:34 2013 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Tue Nov 5 08:17:34 2013 -0500 Merge branch 'master' into next --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.12-4897-gdf8bb56
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, next has been updated
via df8bb5647814be4a5df1b0f22e0658ec62c5beb5 (commit)
via 5cf1120fbf11fcc6bb5f5f15b0e2c8472bafc261 (commit)
from 2dd5c0d0d2481a78b9d20ef769c11be03d376dbc (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 -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=df8bb5647814be4a5df1b0f22e0658ec62c5beb5
commit df8bb5647814be4a5df1b0f22e0658ec62c5beb5
Merge: 2dd5c0d 5cf1120
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Nov 5 08:53:24 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Nov 5 08:53:24 2013 -0500
Merge topic 'clear-generator-data' into next
5cf1120 cmGlobalGenerator: Refactor member cleanup between configures
diff --cc Source/cmGlobalGenerator.h
index 2e20a4d,4529060..d9d5e61
--- a/Source/cmGlobalGenerator.h
+++ b/Source/cmGlobalGenerator.h
@@@ -414,11 -412,11 +414,12 @@@ private
// Per-target generator information.
cmGeneratorTargetsType GeneratorTargets;
void CreateGeneratorTargets();
+ void FinalizeTargetCompileDefinitions();
void ComputeGeneratorTargetObjects();
- void ClearGeneratorTargets();
virtual void ComputeTargetObjects(cmGeneratorTarget* gt) const;
+ void ClearGeneratorMembers();
+
// Cache directory content and target files to be built.
struct DirectoryContent: public std::setcmStdString
{
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5cf1120fbf11fcc6bb5f5f15b0e2c8472bafc261
commit 5cf1120fbf11fcc6bb5f5f15b0e2c8472bafc261
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Nov 4 16:06:51 2013 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Tue Nov 5 07:27:42 2013 -0500
cmGlobalGenerator: Refactor member cleanup between configures
Factor member cleanup out from cmGlobalGenerator::Configure and the
destructor into a dedicated helper to avoid duplication. This fixes
clearing of BuildExportSets between configures.
diff --git a/Source/cmGlobalGenerator.cxx b/Source/cmGlobalGenerator.cxx
index dd7311e..f7c4b94 100644
--- a/Source/cmGlobalGenerator.cxx
+++ b/Source/cmGlobalGenerator.cxx
@@ -66,32 +66,12 @@ cmGlobalGenerator::cmGlobalGenerator()
cmGlobalGenerator::~cmGlobalGenerator()
{
- // Delete any existing cmLocalGenerators
- for (unsigned int i = 0; i this-LocalGenerators.size(); ++i)
-{
-delete this-LocalGenerators[i];
-}
- for(std::vectorcmGeneratorExpressionEvaluationFile*::const_iterator
- li = this-EvaluationFiles.begin();
- li != this-EvaluationFiles.end();
- ++li)
-{
-delete *li;
-}
- for(std::mapstd::string, cmExportBuildFileGenerator*::iterator
-i = this-BuildExportSets.begin();
- i != this-BuildExportSets.end(); ++i)
-{
-delete i-second;
-}
- this-LocalGenerators.clear();
+ this-ClearGeneratorMembers();
if (this-ExtraGenerator)
{
delete this-ExtraGenerator;
}
-
- this-ClearGeneratorTargets();
}
bool cmGlobalGenerator::SetGeneratorToolset(std::string const ts)
@@ -970,31 +950,7 @@ bool cmGlobalGenerator::IsDependedOn(const char* project,
void cmGlobalGenerator::Configure()
{
this-FirstTimeProgress = 0.0f;
- this-ClearGeneratorTargets();
- this-ExportSets.clear();
- // Delete any existing cmLocalGenerators
- unsigned int i;
- for (i = 0; i this-LocalGenerators.size(); ++i)
-{
-delete this-LocalGenerators[i];
-}
- this-LocalGenerators.clear();
- for(std::vectorcmGeneratorExpressionEvaluationFile*::const_iterator
- li = this-EvaluationFiles.begin();
- li != this-EvaluationFiles.end();
- ++li)
-{
-delete *li;
-}
- this-EvaluationFiles.clear();
- this-TargetDependencies.clear();
- this-TotalTargets.clear();
- this-ImportedTargets.clear();
- this-LocalGeneratorToTargetMap.clear();
- this-ProjectMap.clear();
- this-RuleHashes.clear();
- this-DirectoryContentMap.clear();
- this-BinaryDirectories.clear();
+ this-ClearGeneratorMembers();
// start with this directory
cmLocalGenerator *lg = this-CreateLocalGenerator();
@@ -1383,7 +1339,7 @@ void cmGlobalGenerator::ComputeGeneratorTargetObjects()
}
//
-void cmGlobalGenerator::ClearGeneratorTargets()
+void cmGlobalGenerator::ClearGeneratorMembers()
{
for(cmGeneratorTargetsType::iterator i = this-GeneratorTargets.begin();
i != this-GeneratorTargets.end(); ++i)
@@ -1391,6 +1347,39 @@ void cmGlobalGenerator::ClearGeneratorTargets()
delete i-second;
}
this-GeneratorTargets.clear();
+
+
[Cmake-commits] CMake branch, next, updated. v2.8.12-4902-g9a6dc37
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, next has been updated
via 9a6dc3717e504e781a0a6664207995a56095e363 (commit)
via 0018cbd9077d577276a8947029113e122b078e00 (commit)
from 8d75f6b5f6eb365136259f29a381017d0d960efb (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 -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9a6dc3717e504e781a0a6664207995a56095e363
commit 9a6dc3717e504e781a0a6664207995a56095e363
Merge: 8d75f6b 0018cbd
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Tue Nov 5 09:36:59 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Nov 5 09:36:59 2013 -0500
Merge topic 'fix-autogen-definitions' into next
0018cbd cmQtAutogen: Gather tool arguments after creating generator targets.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0018cbd9077d577276a8947029113e122b078e00
commit 0018cbd9077d577276a8947029113e122b078e00
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Mon Nov 4 10:34:54 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Tue Nov 5 15:36:39 2013 +0100
cmQtAutogen: Gather tool arguments after creating generator targets.
One of the side-effects in cmGlobalGenerator::CreateGeneratorTargets
is that compile definitions from the makefile are appended to the
target. Compile definitions are read from the target directly for
generating the buildsystem, and generating the Autogen info too
early caused incomplete compile definitions to be used (#14535).
The compile definitions related code will be moved out of
CreateGeneratorTargets in a followup commit. However this change
also has the independent benefit that it causes the
GetLinkInterfaceDependentStringProperty method to be called in
SetupAutoGenerateTarget, after the creation of generator targets. In
CMake 4.0, the GetLinkInterfaceDependentStringProperty will move to
the cmGeneratorTarget class, and this is a necessary prerequisite to
that.
diff --git a/Source/cmGlobalGenerator.cxx b/Source/cmGlobalGenerator.cxx
index eac54c3..7d99abe 100644
--- a/Source/cmGlobalGenerator.cxx
+++ b/Source/cmGlobalGenerator.cxx
@@ -1097,7 +1097,8 @@ void cmGlobalGenerator::Generate()
// Iterate through all targets and set up automoc for those which have
// the AUTOMOC, AUTOUIC or AUTORCC property set
- this-CreateQtAutoGeneratorsTargets();
+ AutogensType autogens;
+ this-CreateQtAutoGeneratorsTargets(autogens);
// For each existing cmLocalGenerator
unsigned int i;
@@ -1131,6 +1132,12 @@ void cmGlobalGenerator::Generate()
// Create per-target generator information.
this-CreateGeneratorTargets();
+ for (AutogensType::iterator it = autogens.begin(); it != autogens.end();
+ ++it)
+{
+it-first.SetupAutoGenerateTarget(it-second);
+}
+
// Trace the dependencies, after that no custom commands should be added
// because their dependencies might not be handled correctly
for (i = 0; i this-LocalGenerators.size(); ++i)
@@ -1256,11 +1263,9 @@ bool cmGlobalGenerator::CheckTargets()
}
//
-void cmGlobalGenerator::CreateQtAutoGeneratorsTargets()
+void cmGlobalGenerator::CreateQtAutoGeneratorsTargets(AutogensType autogens)
{
#ifdef CMAKE_BUILD_WITH_CMAKE
- typedef std::vectorstd::paircmQtAutoGenerators, cmTarget* Autogens;
- Autogens autogens;
for(unsigned int i=0; i this-LocalGenerators.size(); ++i)
{
cmTargets targets =
@@ -1289,11 +1294,8 @@ void cmGlobalGenerator::CreateQtAutoGeneratorsTargets()
}
}
}
- for (Autogens::iterator it = autogens.begin(); it != autogens.end();
- ++it)
-{
-it-first.SetupAutoGenerateTarget(it-second);
-}
+#else
+ (void)autogens;
#endif
}
diff --git a/Source/cmGlobalGenerator.h b/Source/cmGlobalGenerator.h
index 4d6e10f..d08ae2a 100644
--- a/Source/cmGlobalGenerator.h
+++ b/Source/cmGlobalGenerator.h
@@ -32,6 +32,7 @@ class cmTarget;
class cmInstallTargetGenerator;
class cmInstallFilesGenerator;
class cmExportBuildFileGenerator;
+class cmQtAutoGenerators;
/** \class cmGlobalGenerator
* \brief Responable for overseeing the generation process for the entire tree
@@ -323,7 +324,8 @@ protected:
virtual bool CheckALLOW_DUPLICATE_CUSTOM_TARGETS();
bool CheckTargets();
- void CreateQtAutoGeneratorsTargets();
+ typedef std::vectorstd::paircmQtAutoGenerators, cmTarget* AutogensType;
+ void CreateQtAutoGeneratorsTargets(AutogensType autogens);
// Fill the ProjectMap, this must be called after LocalGenerators
diff --git a/Tests/QtAutogen/foo.h
[Cmake-commits] CMake branch, next, updated. v2.8.12-4904-gdb76e18
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, next has been updated
via db76e18efa3c52a502877b8963839eded4dfc81f (commit)
via a74918213d6307e037e4510806a22c029b83b33e (commit)
from 9a6dc3717e504e781a0a6664207995a56095e363 (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 -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=db76e18efa3c52a502877b8963839eded4dfc81f
commit db76e18efa3c52a502877b8963839eded4dfc81f
Merge: 9a6dc37 a749182
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Tue Nov 5 09:38:18 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Nov 5 09:38:18 2013 -0500
Merge topic 'fix-autogen-definitions' into next
a749182 cmQtAutogen: Skip during bootstrap of CMake
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a74918213d6307e037e4510806a22c029b83b33e
commit a74918213d6307e037e4510806a22c029b83b33e
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Nov 4 18:26:11 2013 -0500
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Tue Nov 5 15:37:43 2013 +0100
cmQtAutogen: Skip during bootstrap of CMake
diff --git a/Source/cmGlobalGenerator.cxx b/Source/cmGlobalGenerator.cxx
index 7d99abe..85c467d 100644
--- a/Source/cmGlobalGenerator.cxx
+++ b/Source/cmGlobalGenerator.cxx
@@ -1095,10 +1095,12 @@ void cmGlobalGenerator::Generate()
return;
}
+#ifdef CMAKE_BUILD_WITH_CMAKE
// Iterate through all targets and set up automoc for those which have
// the AUTOMOC, AUTOUIC or AUTORCC property set
AutogensType autogens;
this-CreateQtAutoGeneratorsTargets(autogens);
+#endif
// For each existing cmLocalGenerator
unsigned int i;
@@ -1132,11 +1134,13 @@ void cmGlobalGenerator::Generate()
// Create per-target generator information.
this-CreateGeneratorTargets();
+#ifdef CMAKE_BUILD_WITH_CMAKE
for (AutogensType::iterator it = autogens.begin(); it != autogens.end();
++it)
{
it-first.SetupAutoGenerateTarget(it-second);
}
+#endif
// Trace the dependencies, after that no custom commands should be added
// because their dependencies might not be handled correctly
---
Summary of changes:
Source/cmGlobalGenerator.cxx |4
1 files changed, 4 insertions(+), 0 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.12-4908-g50e1986
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, next has been updated
via 50e198662393993223a08e12599e344c67743788 (commit)
via c971939a60dc6d553ed3df88945bbac20ae7b574 (commit)
from 19f944fe4d5b41d409654e30e9c03c5043bda9db (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 -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=50e198662393993223a08e12599e344c67743788
commit 50e198662393993223a08e12599e344c67743788
Merge: 19f944f c971939
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Tue Nov 5 09:39:38 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Nov 5 09:39:38 2013 -0500
Merge topic 'fix-autogen-definitions' into next
c971939 Extract FinalizeTargetCompileDefinitions from cmGeneratorTarget.
diff --cc Source/cmGlobalGenerator.h
index bd873ce,2e20a4d..d9d5e61
--- a/Source/cmGlobalGenerator.h
+++ b/Source/cmGlobalGenerator.h
@@@ -414,11 -414,11 +414,12 @@@ private
// Per-target generator information.
cmGeneratorTargetsType GeneratorTargets;
void CreateGeneratorTargets();
+ void FinalizeTargetCompileDefinitions();
void ComputeGeneratorTargetObjects();
- void ClearGeneratorTargets();
virtual void ComputeTargetObjects(cmGeneratorTarget* gt) const;
+ void ClearGeneratorMembers();
+
// Cache directory content and target files to be built.
struct DirectoryContent: public std::setcmStdString
{
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c971939a60dc6d553ed3df88945bbac20ae7b574
commit c971939a60dc6d553ed3df88945bbac20ae7b574
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Mon Nov 4 10:51:37 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Tue Nov 5 15:39:12 2013 +0100
Extract FinalizeTargetCompileDefinitions from cmGeneratorTarget.
Call the method early in the generate step.
diff --git a/Source/cmGlobalGenerator.cxx b/Source/cmGlobalGenerator.cxx
index 85c467d..2ffd478 100644
--- a/Source/cmGlobalGenerator.cxx
+++ b/Source/cmGlobalGenerator.cxx
@@ -1095,6 +1095,8 @@ void cmGlobalGenerator::Generate()
return;
}
+ this-FinalizeTargetCompileDefinitions();
+
#ifdef CMAKE_BUILD_WITH_CMAKE
// Iterate through all targets and set up automoc for those which have
// the AUTOMOC, AUTOUIC or AUTORCC property set
@@ -1304,13 +1306,11 @@ void
cmGlobalGenerator::CreateQtAutoGeneratorsTargets(AutogensType autogens)
}
//
-void cmGlobalGenerator::CreateGeneratorTargets()
+void cmGlobalGenerator::FinalizeTargetCompileDefinitions()
{
// Construct per-target generator information.
for(unsigned int i=0; i this-LocalGenerators.size(); ++i)
{
-cmGeneratorTargetsType generatorTargets;
-
cmMakefile *mf = this-LocalGenerators[i]-GetMakefile();
const std::vectorcmValueWithOrigin noconfig_compile_definitions =
@@ -1325,7 +1325,6 @@ void cmGlobalGenerator::CreateGeneratorTargets()
{
cmTarget* t = ti-second;
- {
for (std::vectorcmValueWithOrigin::const_iterator it
= noconfig_compile_definitions.begin();
it != noconfig_compile_definitions.end(); ++it)
@@ -1342,7 +1341,24 @@ void cmGlobalGenerator::CreateGeneratorTargets()
mf-GetProperty(defPropName.c_str()));
}
}
+}
+}
+
+//
+void cmGlobalGenerator::CreateGeneratorTargets()
+{
+ // Construct per-target generator information.
+ for(unsigned int i=0; i this-LocalGenerators.size(); ++i)
+{
+cmGeneratorTargetsType generatorTargets;
+
+cmMakefile *mf = this-LocalGenerators[i]-GetMakefile();
+cmTargets targets = mf-GetTargets();
+for(cmTargets::iterator ti = targets.begin();
+ti != targets.end(); ++ti)
+ {
+ cmTarget* t = ti-second;
cmGeneratorTarget* gt = new cmGeneratorTarget(t);
this-GeneratorTargets[t] = gt;
generatorTargets[t] = gt;
diff --git a/Source/cmGlobalGenerator.h b/Source/cmGlobalGenerator.h
index d08ae2a..2e20a4d 100644
--- a/Source/cmGlobalGenerator.h
+++ b/Source/cmGlobalGenerator.h
@@ -414,6 +414,7 @@ private:
// Per-target generator information.
cmGeneratorTargetsType GeneratorTargets;
void CreateGeneratorTargets();
+ void FinalizeTargetCompileDefinitions();
void ComputeGeneratorTargetObjects();
void ClearGeneratorTargets();
virtual void ComputeTargetObjects(cmGeneratorTarget* gt) const;
---
Summary of changes:
[Cmake-commits] CMake branch, next, updated. v2.8.12-4911-g41519f0
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, next has been updated via 41519f0ee7342fa6aa0c894cde09e922049143b8 (commit) via 177f5e51d2a73202b44acfd8e26312c1480ffdd7 (commit) via d9600f98802d52e14cf3b2e4cdc143bed7f5778a (commit) from 50e198662393993223a08e12599e344c67743788 (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 - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=41519f0ee7342fa6aa0c894cde09e922049143b8 commit 41519f0ee7342fa6aa0c894cde09e922049143b8 Merge: 50e1986 177f5e5 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Nov 5 11:42:26 2013 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Tue Nov 5 11:42:26 2013 -0500 Merge branch 'master' into next --- Summary of changes: hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.12-4914-gcec727e
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, next has been updated
via cec727efe60fffd0fd5a5beb61ce9ec86964980d (commit)
via 246d4269ef03116f265ab4edf9192d92d4bd553e (commit)
via 020ac2426b7a02d40885e96d346832cda1dea780 (commit)
from 41519f0ee7342fa6aa0c894cde09e922049143b8 (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 -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cec727efe60fffd0fd5a5beb61ce9ec86964980d
commit cec727efe60fffd0fd5a5beb61ce9ec86964980d
Merge: 41519f0 246d426
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Tue Nov 5 11:44:58 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Nov 5 11:44:58 2013 -0500
Merge topic 'fix-autogen-definitions' into next
246d426 Revert cmQtAutogen: Gather tool arguments after creating generator
targets.
020ac24 Revert Extract FinalizeTargetCompileDefinitions from
cmGeneratorTarget.
diff --cc Source/cmGlobalGenerator.h
index d9d5e61,4d6e10f..4529060
--- a/Source/cmGlobalGenerator.h
+++ b/Source/cmGlobalGenerator.h
@@@ -414,12 -412,10 +412,11 @@@ private
// Per-target generator information.
cmGeneratorTargetsType GeneratorTargets;
void CreateGeneratorTargets();
- void FinalizeTargetCompileDefinitions();
void ComputeGeneratorTargetObjects();
- void ClearGeneratorTargets();
virtual void ComputeTargetObjects(cmGeneratorTarget* gt) const;
+ void ClearGeneratorMembers();
+
// Cache directory content and target files to be built.
struct DirectoryContent: public std::setcmStdString
{
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=246d4269ef03116f265ab4edf9192d92d4bd553e
commit 246d4269ef03116f265ab4edf9192d92d4bd553e
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Tue Nov 5 17:44:25 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Tue Nov 5 17:44:25 2013 +0100
Revert cmQtAutogen: Gather tool arguments after creating generator
targets.
This reverts commit 28ba5176d9cb13ba1793f9fc599038f92e6334f6.
diff --git a/Source/cmGlobalGenerator.cxx b/Source/cmGlobalGenerator.cxx
index 85c467d..eac54c3 100644
--- a/Source/cmGlobalGenerator.cxx
+++ b/Source/cmGlobalGenerator.cxx
@@ -1095,12 +1095,9 @@ void cmGlobalGenerator::Generate()
return;
}
-#ifdef CMAKE_BUILD_WITH_CMAKE
// Iterate through all targets and set up automoc for those which have
// the AUTOMOC, AUTOUIC or AUTORCC property set
- AutogensType autogens;
- this-CreateQtAutoGeneratorsTargets(autogens);
-#endif
+ this-CreateQtAutoGeneratorsTargets();
// For each existing cmLocalGenerator
unsigned int i;
@@ -1134,14 +1131,6 @@ void cmGlobalGenerator::Generate()
// Create per-target generator information.
this-CreateGeneratorTargets();
-#ifdef CMAKE_BUILD_WITH_CMAKE
- for (AutogensType::iterator it = autogens.begin(); it != autogens.end();
- ++it)
-{
-it-first.SetupAutoGenerateTarget(it-second);
-}
-#endif
-
// Trace the dependencies, after that no custom commands should be added
// because their dependencies might not be handled correctly
for (i = 0; i this-LocalGenerators.size(); ++i)
@@ -1267,9 +1256,11 @@ bool cmGlobalGenerator::CheckTargets()
}
//
-void cmGlobalGenerator::CreateQtAutoGeneratorsTargets(AutogensType autogens)
+void cmGlobalGenerator::CreateQtAutoGeneratorsTargets()
{
#ifdef CMAKE_BUILD_WITH_CMAKE
+ typedef std::vectorstd::paircmQtAutoGenerators, cmTarget* Autogens;
+ Autogens autogens;
for(unsigned int i=0; i this-LocalGenerators.size(); ++i)
{
cmTargets targets =
@@ -1298,8 +1289,11 @@ void
cmGlobalGenerator::CreateQtAutoGeneratorsTargets(AutogensType autogens)
}
}
}
-#else
- (void)autogens;
+ for (Autogens::iterator it = autogens.begin(); it != autogens.end();
+ ++it)
+{
+it-first.SetupAutoGenerateTarget(it-second);
+}
#endif
}
diff --git a/Source/cmGlobalGenerator.h b/Source/cmGlobalGenerator.h
index d08ae2a..4d6e10f 100644
--- a/Source/cmGlobalGenerator.h
+++ b/Source/cmGlobalGenerator.h
@@ -32,7 +32,6 @@ class cmTarget;
class cmInstallTargetGenerator;
class cmInstallFilesGenerator;
class cmExportBuildFileGenerator;
-class cmQtAutoGenerators;
/** \class cmGlobalGenerator
* \brief Responable for overseeing the generation process for the entire tree
@@ -324,8 +323,7 @@ protected:
virtual bool CheckALLOW_DUPLICATE_CUSTOM_TARGETS();
bool CheckTargets();
- typedef std::vectorstd::paircmQtAutoGenerators, cmTarget* AutogensType;
- void CreateQtAutoGeneratorsTargets(AutogensType autogens);
[Cmake-commits] CMake branch, next, updated. v2.8.12-4917-gc773200
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, next has been updated via c773200186f13747b55bbd1e938644312c9cfc1f (commit) via d53466ef4b43cf2ec14f57161bf3fcc47bbbe626 (commit) via 5eed0f404c865205351cc157dd796f4b55db7e74 (commit) from cec727efe60fffd0fd5a5beb61ce9ec86964980d (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 - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c773200186f13747b55bbd1e938644312c9cfc1f commit c773200186f13747b55bbd1e938644312c9cfc1f Merge: cec727e d53466e Author: Brad King brad.k...@kitware.com AuthorDate: Tue Nov 5 11:45:18 2013 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Nov 5 11:45:18 2013 -0500 Merge topic 'test-release' into next d53466e Merge branch 'release' into test-release 5eed0f4 Revert CMake 2.8.12.1 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d53466ef4b43cf2ec14f57161bf3fcc47bbbe626 commit d53466ef4b43cf2ec14f57161bf3fcc47bbbe626 Merge: f68a4a2 5eed0f4 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Nov 5 11:44:33 2013 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Tue Nov 5 11:44:33 2013 -0500 Merge branch 'release' into test-release http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5eed0f404c865205351cc157dd796f4b55db7e74 commit 5eed0f404c865205351cc157dd796f4b55db7e74 Author: Brad King brad.k...@kitware.com AuthorDate: Tue Nov 5 11:44:17 2013 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Tue Nov 5 11:44:17 2013 -0500 Revert CMake 2.8.12.1 This reverts commit c438cdb5869aa00eb8426924152d2d5f3bd6f3c5. diff --git a/ChangeLog.manual b/ChangeLog.manual index e86d890..0e84fb6 100644 --- a/ChangeLog.manual +++ b/ChangeLog.manual @@ -1,28 +1,3 @@ -Changes in CMake 2.8.12.1 (since 2.8.12) - -Brad King (9): - MSVC: Add /FS flag for cl = 18 to allow parallel compilation (#14492) - Genex: Reject $TARGET_FILE:... for object libraries (#14532) - Check for OBJECT_LIBRARY source files at start of generation - CMP0022: Plain target_link_libraries must populate link interface - Do not export INTERFACE_LINK_LIBRARIES from non-linkable targets - CMP0022: Warn about a given target at most once - Fix summary documentation of INTERFACE_LINK_LIBRARIES - file(GENERATE): Clear internal records between configures - cmake: Validate -E cmake_automoc argument count (#14545) - -Modestas Vainius (1): - Fix spelling in INTERFACE_LINK_LIBRARIES documentation (#14542) - -Stephen Kelly (4): - CMP0022: Output link interface mismatch for static library warning - Don't add invalid content to static lib INTERFACE_LINK_LIBRARIES. - CMP0022: Add unit test for null pointer check and message. - CMP0022: Add test for target_link_libraries plain signature - -Vladislav Vinogradov (1): - FindCUDA: Fix NPP library search for CUDA 5.5 - Changes in CMake 2.8.12 (since 2.8.12-rc4) -- Brad King (4): diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 5027370..63751fb 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -2,5 +2,5 @@ set(CMake_VERSION_MAJOR 2) set(CMake_VERSION_MINOR 8) set(CMake_VERSION_PATCH 12) -set(CMake_VERSION_TWEAK 1) +set(CMake_VERSION_TWEAK 0) #set(CMake_VERSION_RC 0) --- Summary of changes: ChangeLog.manual | 25 - 1 files changed, 0 insertions(+), 25 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.12-4919-g734ea51
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, next has been updated
via 734ea519ea79af7a438adf1d3a7eea6fa63ec323 (commit)
via 0a39685fa6a986eae86ca9868e44cbc38da3cddf (commit)
from c773200186f13747b55bbd1e938644312c9cfc1f (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 -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=734ea519ea79af7a438adf1d3a7eea6fa63ec323
commit 734ea519ea79af7a438adf1d3a7eea6fa63ec323
Merge: c773200 0a39685
Author: Peter Kuemmel syntheti...@gmx.net
AuthorDate: Tue Nov 5 11:48:05 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Nov 5 11:48:05 2013 -0500
Merge topic 'ninja-edit-cache' into next
0a39685 Ninja: run cmake-gui for target edit_cache
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0a39685fa6a986eae86ca9868e44cbc38da3cddf
commit 0a39685fa6a986eae86ca9868e44cbc38da3cddf
Author: Peter Kümmel syntheti...@gmx.net
AuthorDate: Tue Nov 5 17:35:18 2013 +0100
Commit: Peter Kümmel syntheti...@gmx.net
CommitDate: Tue Nov 5 17:35:18 2013 +0100
Ninja: run cmake-gui for target edit_cache
Ninja can't run commands interactively,
this will never work with ninja by design,
so start cmake-gui instead.
http://cmake.org/Bug/view.php?id=14544
diff --git a/Source/cmGlobalGenerator.cxx b/Source/cmGlobalGenerator.cxx
index dd7311e..16d80e4 100644
--- a/Source/cmGlobalGenerator.cxx
+++ b/Source/cmGlobalGenerator.cxx
@@ -2046,6 +2046,11 @@ void cmGlobalGenerator::SetCMakeInstance(cmake* cm)
this-CMakeInstance = cm;
}
+const char* cmGlobalGenerator::GetEditCacheCommand(cmMakefile* mf) const
+{
+ return mf-GetDefinition(CMAKE_EDIT_COMMAND);
+}
+
void cmGlobalGenerator::CreateDefaultGlobalTargets(cmTargets* targets)
{
cmMakefile* mf = this-LocalGenerators[0]-GetMakefile();
@@ -2152,9 +2157,9 @@ void
cmGlobalGenerator::CreateDefaultGlobalTargets(cmTargets* targets)
// Use CMAKE_EDIT_COMMAND for the edit_cache rule if it is defined.
// Otherwise default to the interactive command-line interface.
-if(mf-GetDefinition(CMAKE_EDIT_COMMAND))
+if (this-GetEditCacheCommand(mf))
{
- singleLine.push_back(mf-GetDefinition(CMAKE_EDIT_COMMAND));
+ singleLine.push_back(this-GetEditCacheCommand(mf));
singleLine.push_back(-H$(CMAKE_SOURCE_DIR));
singleLine.push_back(-B$(CMAKE_BINARY_DIR));
cpackCommandLines.push_back(singleLine);
diff --git a/Source/cmGlobalGenerator.h b/Source/cmGlobalGenerator.h
index 4d6e10f..cae3ff5 100644
--- a/Source/cmGlobalGenerator.h
+++ b/Source/cmGlobalGenerator.h
@@ -409,6 +409,8 @@ private:
typedef std::mapcmTarget *, TargetDependSet TargetDependMap;
TargetDependMap TargetDependencies;
+ virtual const char* GetEditCacheCommand(cmMakefile* mf) const;
+
// Per-target generator information.
cmGeneratorTargetsType GeneratorTargets;
void CreateGeneratorTargets();
diff --git a/Source/cmGlobalNinjaGenerator.cxx
b/Source/cmGlobalNinjaGenerator.cxx
index d262397..6e45f21 100644
--- a/Source/cmGlobalNinjaGenerator.cxx
+++ b/Source/cmGlobalNinjaGenerator.cxx
@@ -1199,3 +1199,10 @@ void
cmGlobalNinjaGenerator::WriteTargetHelp(std::ostream os)
/*orderOnlyDeps=*/ cmNinjaDeps(),
/*variables=*/ cmNinjaVars());
}
+
+
+const char* cmGlobalNinjaGenerator::GetEditCacheCommand(cmMakefile* mf) const
+{
+ const char* cmd = mf-GetDefinition(CMAKE_EDIT_COMMAND);
+ return cmd ? cmd : cmake-gui;
+}
diff --git a/Source/cmGlobalNinjaGenerator.h b/Source/cmGlobalNinjaGenerator.h
index be58df1..03d0252 100644
--- a/Source/cmGlobalNinjaGenerator.h
+++ b/Source/cmGlobalNinjaGenerator.h
@@ -222,6 +222,7 @@ public:
}
virtual const char* GetCleanTargetName() const { return clean; }
+ virtual const char* GetEditCacheCommand(cmMakefile* mf) const;
cmGeneratedFileStream* GetBuildFileStream() const {
return this-BuildFileStream; }
---
Summary of changes:
Source/cmGlobalGenerator.cxx |9 +++--
Source/cmGlobalGenerator.h|2 ++
Source/cmGlobalNinjaGenerator.cxx |7 +++
Source/cmGlobalNinjaGenerator.h |1 +
4 files changed, 17 insertions(+), 2 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.12-4931-g5cb35e8
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, next has been updated
via 5cb35e87647d05c7a79b5c5ba7d9bff0165b6fbd (commit)
via e6d2bdfcc2ff54ba482bfdfa028066b8b9a77f78 (commit)
from 3b1f5e611b76bfb61b89a8469df512387a643d1e (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 -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5cb35e87647d05c7a79b5c5ba7d9bff0165b6fbd
commit 5cb35e87647d05c7a79b5c5ba7d9bff0165b6fbd
Merge: 3b1f5e6 e6d2bdf
Author: Peter Kuemmel syntheti...@gmx.net
AuthorDate: Tue Nov 5 13:35:51 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Nov 5 13:35:51 2013 -0500
Merge topic 'ninja-edit-cache' into next
e6d2bdf Ninja: run cmake-gui for target edit_cache
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e6d2bdfcc2ff54ba482bfdfa028066b8b9a77f78
commit e6d2bdfcc2ff54ba482bfdfa028066b8b9a77f78
Author: Peter Kümmel syntheti...@gmx.net
AuthorDate: Tue Nov 5 17:35:18 2013 +0100
Commit: Peter Kümmel syntheti...@gmx.net
CommitDate: Tue Nov 5 19:24:27 2013 +0100
Ninja: run cmake-gui for target edit_cache
Ninja can't run commands interactively,
this will never work with ninja by design,
so start cmake-gui instead.
http://cmake.org/Bug/view.php?id=14544
diff --git a/Source/cmGlobalGenerator.cxx b/Source/cmGlobalGenerator.cxx
index dd7311e..16d80e4 100644
--- a/Source/cmGlobalGenerator.cxx
+++ b/Source/cmGlobalGenerator.cxx
@@ -2046,6 +2046,11 @@ void cmGlobalGenerator::SetCMakeInstance(cmake* cm)
this-CMakeInstance = cm;
}
+const char* cmGlobalGenerator::GetEditCacheCommand(cmMakefile* mf) const
+{
+ return mf-GetDefinition(CMAKE_EDIT_COMMAND);
+}
+
void cmGlobalGenerator::CreateDefaultGlobalTargets(cmTargets* targets)
{
cmMakefile* mf = this-LocalGenerators[0]-GetMakefile();
@@ -2152,9 +2157,9 @@ void
cmGlobalGenerator::CreateDefaultGlobalTargets(cmTargets* targets)
// Use CMAKE_EDIT_COMMAND for the edit_cache rule if it is defined.
// Otherwise default to the interactive command-line interface.
-if(mf-GetDefinition(CMAKE_EDIT_COMMAND))
+if (this-GetEditCacheCommand(mf))
{
- singleLine.push_back(mf-GetDefinition(CMAKE_EDIT_COMMAND));
+ singleLine.push_back(this-GetEditCacheCommand(mf));
singleLine.push_back(-H$(CMAKE_SOURCE_DIR));
singleLine.push_back(-B$(CMAKE_BINARY_DIR));
cpackCommandLines.push_back(singleLine);
diff --git a/Source/cmGlobalGenerator.h b/Source/cmGlobalGenerator.h
index 4d6e10f..cae3ff5 100644
--- a/Source/cmGlobalGenerator.h
+++ b/Source/cmGlobalGenerator.h
@@ -409,6 +409,8 @@ private:
typedef std::mapcmTarget *, TargetDependSet TargetDependMap;
TargetDependMap TargetDependencies;
+ virtual const char* GetEditCacheCommand(cmMakefile* mf) const;
+
// Per-target generator information.
cmGeneratorTargetsType GeneratorTargets;
void CreateGeneratorTargets();
diff --git a/Source/cmGlobalNinjaGenerator.h b/Source/cmGlobalNinjaGenerator.h
index be58df1..e557b82 100644
--- a/Source/cmGlobalNinjaGenerator.h
+++ b/Source/cmGlobalNinjaGenerator.h
@@ -222,6 +222,8 @@ public:
}
virtual const char* GetCleanTargetName() const { return clean; }
+ virtual const char* GetEditCacheCommand(cmMakefile* mf) const {
+return cmake-gui; }
cmGeneratedFileStream* GetBuildFileStream() const {
return this-BuildFileStream; }
---
Summary of changes:
Source/cmGlobalGenerator.cxx|9 +++--
Source/cmGlobalGenerator.h |2 ++
Source/cmGlobalNinjaGenerator.h |2 ++
3 files changed, 11 insertions(+), 2 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
