Re: [cmake-developers] Rebase or not?
On 1/2/2012 7:25 PM, Eric Noulard wrote: Just pushed it forward on stage: see: http://public.kitware.com/Bug/view.php?id=10067 It looks like it cannot be merged [automatically] to next anymore. It is possible that the conflicting change is already in master. That is a justification to merge master into your topic to resolve the conflict, or rebase your topic on master to resolve it. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CheckSymbolExists is unreliable
On 1/2/2012 5:24 PM, Rolf Eike Beer wrote:
It looks like gcc simply optimizes out any reference to the tested symbol.
Given the fact that we don't really ever use that symbol anywhere it is even
correct to do so. Just that this is not what we want.
Yuck. Clearly a less-optimizable approach is needed.
I pushed a topic test-symbol-exists to stage that verifies that this is indeed
a problem in Check{,CXX}SymbolExists, it iterates through all build
configurations (were this problem does _not_ happen) and later explicitely
adds a -O3 test if it is gcc/g++ which then _does_ fail.
So, there are 3 points that I need advise:
-what should happen with this topic? Should I merge it to next? Then we will
get a ton of failures on at least everything that is using GNU compilers.
Certainly we should add tests for these modules. They are critical to
many projects. However, let's not add a test when we know it will break
immediately. Please also rebase the topic so it does not depend on your
FindDoxygen topic. Add a commit prior to the test to fix the behavior
as discussed below.
-which other compilers can be tested this way, I mean using -O3? From what I
know Clang does understand this and even -O4, what is about the Intel one?
Let's start with the GNU case and add more later. I suspect that if we can
convince GCC -O3 to keep the symbol (see below) then no other compiler will
be able to optimize it out.
-how to fix this thing at the end? I was thinking about just doing
#includestdio.h
printf(%s is at %p\n, ${SYMBOL},${SYMBOL}));
Is anyone aware of some place where this wouldn't work? Or should I just put
this in and try out?
We don't want the test to depend on any symbols other than the one tested,
even runtime library symbols. Some cross-compilers may not provide everything
by default. We just need to make the return value depend on the symbol. I
worked this out in Modules/CMakeCCompilerId.c.in. Note that the return
value should also depend on a runtime argument (argc) so the optimizer cannot
make any assumptions.
I think this will work:
int main(int argc, char* argv[])
{
(void)argv;
return ((int*)(SYMBOL))[argc];
}
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Improving CPack Documentation (and may be others as well)
On 1/2/2012 7:43 PM, Eric Noulard wrote: I try to push forward the feature request: http://public.kitware.com/Bug/view.php?id=10067 [snip] Anybody have some time to try this? I'd like to have some feedback before going on. The branch is stage/ImproveCPackDoc. Please factor out the completion, top-level command help, and other changes that do not introduce the new functionality. Put them in their own topic for separate review, and then rebase the main changes on it. That will make this much easier to review and test. Currently the new logic is split across a few commits so it is hard to follow. Thanks, -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Improving CPack Documentation (and may be others as well)
2012/1/3 Brad King brad.k...@kitware.com: On 1/2/2012 7:43 PM, Eric Noulard wrote: I try to push forward the feature request: http://public.kitware.com/Bug/view.php?id=10067 [snip] Anybody have some time to try this? I'd like to have some feedback before going on. The branch is stage/ImproveCPackDoc. Please factor out the completion, top-level command help, and other changes that do not introduce the new functionality. Put them in their own topic for separate review, and then rebase the main changes on it. That will make this much easier to review and test. Currently the new logic is split across a few commits so it is hard to follow. Ok right I'll do that. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- 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] Improving CPack Documentation (and may be others as well)
2012/1/3 Eric Noulard eric.noul...@gmail.com: 2012/1/3 Brad King brad.k...@kitware.com: On 1/2/2012 7:43 PM, Eric Noulard wrote: I try to push forward the feature request: http://public.kitware.com/Bug/view.php?id=10067 [snip] Anybody have some time to try this? I'd like to have some feedback before going on. The branch is stage/ImproveCPackDoc. Please factor out the completion, top-level command help, and other changes that do not introduce the new functionality. Put them in their own topic for separate review, and then rebase the main changes on it. That will make this much easier to review and test. Currently the new logic is split across a few commits so it is hard to follow. stage/CMake-completion-improvement contains the completion update. This can be merged to next/master independently from other because the changes won't be used unless the new options appears stage/ImproveCPackDoc-part1 contains changes that do not add features but document existing ones. Those topics are based on master from this morning (CEST). As such they may be merged to next and then to master as they are. I'll start another branch which will contain new feature only concerning true enhancement. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- 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] Improving CPack Documentation (and may be others as well)
On 1/3/2012 11:03 AM, Eric Noulard wrote:
stage/ImproveCPackDoc-part1
contains changes that do not add features but document existing ones.
This one looks good. Please merge to next.
stage/CMake-completion-improvement
contains the completion update.
This can be merged to next/master independently from other
because the changes won't be used unless the new options appears
So you purposely refer to options that don't yet exist so they will
complete when they do? Is that only this hunk:
+--help-variable)
+local running=$(for x in `cpack --help-variable-list | grep -v cpack
version `; do echo ${x} ; done )
+COMPREPLY=( $(compgen -W ${running} -- ${cur}) )
+return 0
+;;
+--help-command)
+local running=$(for x in `cpack --help-command-list | grep -v cpack
version `; do echo ${x} ; done )
+COMPREPLY=( $(compgen -W ${running} -- ${cur}) )
+return 0
+;;
? I think that can that be left out and then included in the new
enhancement topic. It won't make the topic any harder to review and
makes it clear when the options are added.
I'll start another branch which will contain new feature only concerning
true enhancement.
Thanks!
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Improving CPack Documentation (and may be others as well)
2012/1/3 Brad King brad.k...@kitware.com:
On 1/3/2012 11:03 AM, Eric Noulard wrote:
stage/ImproveCPackDoc-part1
contains changes that do not add features but document existing ones.
This one looks good. Please merge to next.
It does not merge without conflict:
d2c9626 Document undocumented (but existing) cpack options (fix #0010134)
Auto-merging Source/CPack/cpack.cxx
CONFLICT (content): Merge conflict in Source/CPack/cpack.cxx
this is due to the fact I did already merge it
(the beginning of the old stage/ImproveCPackDoc)
to next before 2.8.7 in the hope that it would be included in 2.8.7:
http://public.kitware.com/Bug/view.php?id=10067#c27793
It was dropped because ImproveCPackDoc as a whole wasn't considered ready
which was off course true...
I have to teach myself to provide finer-grain branch merge :-(
The left over commit of mine in next are:
commit ab6c9c03bcdb89717345d68bdc979d74fd776d04
Author: Eric NOULARD eric.noul...@gmail.com
Date: Sun Nov 13 22:47:25 2011 +0100
Update cmake bash completion file.
commit 1e38d6dd306522a0d08355a6c7ef57293b46b5a6
Author: Eric NOULARD eric.noul...@gmail.com
Date: Sun Nov 13 22:44:53 2011 +0100
CPack begin the implementation of --help-command* and --help-variables*
Author: Eric NOULARD eric.noul...@gmail.com
Date: Sat Nov 5 14:41:23 2011 +0100
Document undocumented (but existing) cpack options (fix #0010134)
Tell me how you would like me to handle my mess :-(
stage/CMake-completion-improvement
contains the completion update.
This can be merged to next/master independently from other
because the changes won't be used unless the new options appears
So you purposely refer to options that don't yet exist so they will
complete when they do?
Yes like I said, this is harmless.
In fact I may even implement all normalized options
(--help-[command|variable|property|policy]
completion for cmake/ctest/cpack, if they are not supported they
won't be triggered.
Is that only this hunk:
Yes:
+ --help-variable)
+ local running=$(for x in `cpack --help-variable-list | grep -v
cpack version `; do echo ${x} ; done )
+ COMPREPLY=( $(compgen -W ${running} -- ${cur}) )
+ return 0
+ ;;
+ --help-command)
+ local running=$(for x in `cpack --help-command-list | grep -v
cpack version `; do echo ${x} ; done )
+ COMPREPLY=( $(compgen -W ${running} -- ${cur}) )
+ return 0
+ ;;
? I think that can that be left out and then included in the new
enhancement topic. It won't make the topic any harder to review and
makes it clear when the options are added.
I can do that as well, no problem.
I'll start another branch which will contain new feature only concerning
true enhancement.
Thanks!
No problem.
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
--
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] Improving CPack Documentation (and may be others as well)
On 1/3/2012 11:45 AM, Eric Noulard wrote: this is due to the fact I did already merge it (the beginning of the old stage/ImproveCPackDoc) to next before 2.8.7 in the hope that it would be included in 2.8.7: http://public.kitware.com/Bug/view.php?id=10067#c27793 It was dropped because ImproveCPackDoc as a whole wasn't considered ready which was off course true... [snip] Tell me how you would like me to handle my mess :-( Start a new topic ImproveCPackDoc-revert from the last commit on the original topic that was merged to 'next'. Then revert all the commits that had been merged so far in reverse order. Merge that to next. Then your rebased topics should merge cleanly. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Improving CPack Documentation (and may be others as well)
2012/1/3 Brad King brad.k...@kitware.com: On 1/3/2012 11:45 AM, Eric Noulard wrote: this is due to the fact I did already merge it (the beginning of the old stage/ImproveCPackDoc) to next before 2.8.7 in the hope that it would be included in 2.8.7: http://public.kitware.com/Bug/view.php?id=10067#c27793 It was dropped because ImproveCPackDoc as a whole wasn't considered ready which was off course true... [snip] Tell me how you would like me to handle my mess :-( Start a new topic ImproveCPackDoc-revert from the last commit on the original topic that was merged to 'next'. Then revert all the commits that had been merged so far in reverse order. Merge that to next. Then your rebased topics should merge cleanly. OK, done for Merge topic 'ImproveCPackDoc-part1' into next d2c9626 Document undocumented (but existing) cpack options (fix #0010134) Pushing upstream next To g...@cmake.org:cmake.git I did remove old ImproveCPackDoc from stage. I did remove old CMake-completion-improvement from stage as well and I'll push something clean without reference to potential cpack enhancement in a new topic. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- 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] Improving CPack Documentation (and may be others as well)
2012/1/3 Eric Noulard eric.noul...@gmail.com: I did remove old ImproveCPackDoc from stage. I did remove old CMake-completion-improvement from stage as well and I'll push something clean without reference to potential cpack enhancement in a new topic. Done as well: Merge topic 'CMake-bash-completion-enhance' into next 4d253d1 Enhance bash completion file for cmake and ctest df22472 KWSys Nightly Date Stamp back to cleaner way of work. Thanks for your help. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- 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] Relation between CMAKE_PREFIX_PATH and CMAKE_FIND_ROOT_PATH
Hi All, I have been giving wrong advice about the usage of CMAKE_FIND_ROOT_PATH which seems to be reserved for cross-compiling whereas CMAKE_PREFIX_PATH CMAKE_INCLUDE_PATH CMAKE_PROGRAM_PATH CMAKE_LIBRARY_PATH CMAKE_IGNORE_PATH could someone enlight me about the intended relationship between those var and their SYSTEM counterpart CMAKE_SYSTEM_*_PATH ? CMAKE_*_PATH a -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- 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] Relation between CMAKE_PREFIX_PATH and CMAKE_FIND_ROOT_PATH
Sorry sent too soon, finger slipped. ... I have been giving wrong advice about the usage of CMAKE_FIND_ROOT_PATH which seems to be reserved for cross-compiling whereas CMAKE_PREFIX_PATH CMAKE_INCLUDE_PATH CMAKE_PROGRAM_PATH CMAKE_LIBRARY_PATH CMAKE_IGNORE_PATH are meant to be used in the general case. Could someone enlighten me about the intended usage and relationship between those vars and their SYSTEM counterpart CMAKE_SYSTEM_*_PATH ? And may be why do we need CMAKE_FIND_ROOT_PATH for cross-compiling if CMAKE_PREFIX_PATH already existed? CMAKE_*_PATH are documented (through --help-variables) whereas CMAKE_FIND_ROOT_PATH doesn't seem to be currently. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- 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] Relation between CMAKE_PREFIX_PATH and CMAKE_FIND_ROOT_PATH
On Tuesday 03 January 2012, Eric Noulard wrote: Sorry sent too soon, finger slipped. ... I have been giving wrong advice about the usage of CMAKE_FIND_ROOT_PATH which seems to be reserved for cross-compiling whereas CMAKE_PREFIX_PATH CMAKE_INCLUDE_PATH CMAKE_PROGRAM_PATH CMAKE_LIBRARY_PATH CMAKE_IGNORE_PATH are meant to be used in the general case. Could someone enlighten me about the intended usage and relationship between those vars and their SYSTEM counterpart CMAKE_SYSTEM_*_PATH ? CMAKE_INCLUDE_PATH is a list of directories used by find_file() and find_path(), could include /home/mystuff/include/ CMAKE_PROGRAM_PATH is a list of directories used by find_program(), could include /home/mystuff/bin/ CMAKE_LIBRARY_PATH is a list of directories used by find_library(), could include /home/mystuff/lib/ These were added 2006 I think. Late 2007 or maybe 2008 came CMAKE_PREFIX_PATH. This make the variables above mostly unnecessary. It is a list of directories, where the respective subdirectory is appended by find_program(), find_file() etc. So for the example above you would be done by setting it to /home/mystuff/ . The directories from these variables are checked before the directories given via PATHS or HINTS. CMAKE_FIND_ROOT_PATH is different (and was added before CMAKE_PREFIX_PATH), it is a list of directories which contain root directories where the filesystem of the target system in a cross-compilation setting is location. You set it e.g. to /opt/eldk/arm/. Then cmake will prepend this root dir to each of the directories it would check otherwise. I.e. find_program() will check in /opt/eldk/arm/bin/, /opt/eldk/arm/usr/bin/, /opt/eldk/arm/usr/local/bin/, /opt/eldk/arm/usr/X11/bin/, etc. I.e. the assumption is that under those prefixes a whole normal filesystem is located. 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] Relation between CMAKE_PREFIX_PATH and CMAKE_FIND_ROOT_PATH
On 1/3/2012 1:40 PM, Eric Noulard wrote: I have been giving wrong advice about the usage of CMAKE_FIND_ROOT_PATH which seems to be reserved for cross-compiling whereas Correct. CMAKE_PREFIX_PATH CMAKE_INCLUDE_PATH CMAKE_PROGRAM_PATH CMAKE_LIBRARY_PATH CMAKE_IGNORE_PATH are meant to be used in the general case. Correct. Could someone enlighten me about the intended usage and relationship between those vars and their SYSTEM counterpart CMAKE_SYSTEM_*_PATH ? The SYSTEM_ ones are provided by CMake and are searched later than the others. And may be why do we need CMAKE_FIND_ROOT_PATH for cross-compiling if CMAKE_PREFIX_PATH already existed? CMAKE_FIND_ROOT_PATH reroots all paths regardless of where they came from (evauation of the other variables, arguments to the find_* commands, etc.). Variables like CMAKE_PREFIX_PATH just add more paths. Their values do not need to know about the cross-compiling toolchain root so they can just use /bin. CMAKE_*_PATH are documented (through --help-variables) whereas CMAKE_FIND_ROOT_PATH doesn't seem to be currently. Alex? -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CheckSymbolExists is unreliable
On Tue, Jan 3, 2012 at 2:17 PM, Rolf Eike Beer e...@sf-mail.de wrote:
Sorry, that was not intentional. I dropped the previous branch and created a
new one, based on current master. It has 2 commits: the first one introducing
the (hopefully) fixed CheckSymbolExists.cmake, the second one adding the
tests. It also adds a positive test: it checks if errno can be found in
errno.h for both C and C++. Hope this will not break on some strange machines.
Nice, thanks.
int main(int argc, char* argv[])
{
(void)argv;
return ((int*)(SYMBOL))[argc];
}
It looks like, at least it survives my -O3 test.
Great.
Pushed updated branch. Please review and merge to next if you like it.
Can you handle Modules/CheckPrototypeDefinition.cmake too? I think it
has the same problem.
There are a few problems with the current test. The configured cse.cmake
scripts end up driving the test builds using the CMake that was used to
configure CMake's build tree, not the one that was just built and should
be tested. Also they don't select the generator properly so will only work
on Unix-like systems.
I don't think you need to create a whole new build tree for every test.
You can do all the test try-compiles right in the main test CMakeLists.txt
file, just with different result cache variable names
foreach(_config_type Release RelWithDebInfo MinSizeRel Debug)
set(CMAKE_TRY_COMPILE_CONFIGURATION ${_config_type})
check_symbol_exists(...)
endforeach()
In order to test things like -O3, just add them temporarily to the
CMAKE_C_FLAGS or CMAKE_CXX_FLAGS variables.
Finally, I'd like to tweak the first commit message slightly:
CheckSymbolExists: try to force the compiler to keep the referenced symbol
s/try to//
previous version was not really using this. This lead to symbols that are
s/lead to/leads to/
Thanks,
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0012652]: CMAKE_LANG_FLAGS are passed for linking too, but this causes warnings for compilation-only flags
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=12652
==
Reported By:Sean McBride
Assigned To:
==
Project:CMake
Issue ID: 12652
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2012-01-03 15:49 EST
Last Modified: 2012-01-03 15:49 EST
==
Summary:CMAKE_LANG_FLAGS are passed for linking too, but
this causes warnings for compilation-only flags
Description:
Searching the archives, I see that CMake deliberately passes the
CMAKE_LANG_FLAGS for linking too:
http://www.cmake.org/pipermail/cmake/2010-July/038090.html
If I add -std=c++0x to CMAKE_CXX_FLAGS, then compilation is fine, but clang will
warn when linking:
clang-3: warning: argument unused during compilation: '-std=c++0x'
For one's own projects, one could do something like:
SET_SOURCE_FILES_PROPERTIES(${MYCPPS} PROPERTIES COMPILE_FLAGS --std=c++0x)
But my hope was to use --std=c++0x on my CMake/VTK/ITK dashboards to make sure
their codebases are foreword-compatible with the new language standard.
Above all, it seems weird that something named CMAKE_C_FLAGS is passed to the
linker when we already have CMAKE_EXE_LINKER_FLAGS and the like.
I realize changing this has compatibility implications.
==
Issue History
Date ModifiedUsername FieldChange
==
2012-01-03 15:49 Sean McBride 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-developers] libarchive upstream
Hi Brad, I've seen you are integrating new upstream libarchive today. Any particular reason to pick-up 3.0.0-r3950 and not some real version like 3.0.2 ? I did notice that this particular version may unblock a pending CMake issue related to symbolic link handling in zip files, see: http://public.kitware.com/Bug/view.php?id=10162 Not a big deal but it would be nice to integrate an upstream version of libarchive that handles symlinks in zip file. The interesting upstream commit is slightly of r3950: r3966 | ggcueroad | 2011-12-23 01:19:37 +0100 (ven. 23 déc. 2011) | 2 lignes Add support for symlink to ZIP writer. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- 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] libarchive upstream
On 1/3/2012 4:07 PM, Eric Noulard wrote: I've seen you are integrating new upstream libarchive today. Any particular reason to pick-up 3.0.0-r3950 and not some real version like 3.0.2 ? 3.0.2 wasn't out when I started that topic. I just took that day's snapshot. The main goal/achievement of the work in that topic is to import upstream libarchive in a way that can be easily updated with a new upstream version. I did notice that this particular version may unblock a pending CMake issue related to symbolic link handling in zip files, see: http://public.kitware.com/Bug/view.php?id=10162 Not a big deal but it would be nice to integrate an upstream version of libarchive that handles symlinks in zip file. The interesting upstream commit is slightly of r3950: r3966 | ggcueroad | 2011-12-23 01:19:37 +0100 (ven. 23 déc. 2011) | 2 lignes Add support for symlink to ZIP writer. Nice. Once the initial porting and dashboard cleanup work is done it will be very easy to update to a more recent snapshot whenever we need to. A good time to do it will be the first libarchive release that supports this feature. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] libarchive upstream
2012/1/3 Brad King brad.k...@kitware.com: On 1/3/2012 4:07 PM, Eric Noulard wrote: I've seen you are integrating new upstream libarchive today. Any particular reason to pick-up 3.0.0-r3950 and not some real version like 3.0.2 ? 3.0.2 wasn't out when I started that topic. I just took that day's snapshot. The main goal/achievement of the work in that topic is to import upstream libarchive in a way that can be easily updated with a new upstream version. Ok, I see. The interesting upstream commit is slightly of r3950: r3966 | ggcueroad | 2011-12-23 01:19:37 +0100 (ven. 23 déc. 2011) | 2 lignes Add support for symlink to ZIP writer. Nice. Once the initial porting and dashboard cleanup work is done it will be very easy to update to a more recent snapshot whenever we need to. A good time to do it will be the first libarchive release that supports this feature. 3.0.2 does include the feature: Dec 24, 2011: libarchive 3.0.2 released Dec 23, 2011: Various fixes merged from FreeBSD Dec 23, 2011: Symlink support in Zip reader and writer Dec 23, 2011: Robustness fixes to 7Zip reader Nov 27, 2011: libarchive 3.0.1b released Let's wait for you to finish your experiment with 3.0.0-r3950 then may be the first application of your work may be the integration of 3.0.2 (or better depending on the work in-between). -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- 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] libarchive upstream
On 1/3/2012 4:48 PM, Eric Noulard wrote: 3.0.2 does include the feature: Dec 24, 2011: libarchive 3.0.2 released Great. I started the update work less than a week before that ;) Let's wait for you to finish your experiment with 3.0.0-r3950 then may be the first application of your work may be the integration of 3.0.2 (or better depending on the work in-between). Sounds good. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0012645]: In GenerateExportHeader.cmake IS_ABSOLUTE is used with a variable name instead of a path
Mantis Bug Tracker wrote: The following issue has been SUBMITTED. == http://cmake.org/Bug/view.php?id=12645 == Reported By:Michael Wild Assigned To: Just chiming in to say thanks for the fix. :) -- 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] compiling problem cmake
Hi, On Ubuntu, compiling python 2.5.6 following the instruction listed here [1] works. [1] http://www.vtk.org/Wiki/BuildingPythonWithCMake#Building_Python_for_Linux_or_Windows Somebody with mingw will have to check what's wrong. Step by step: wget http://www.python.org/ftp/python/2.5.6/Python-2.5.6.tgz tar -xzvf Python-2.5.6.tgz cd Python-2.5.6 cvs -d :pserver:anon...@www.paraview.org:/cvsroot/ParaView3 login cvs -d :pserver:anon...@www.paraview.org:/cvsroot/ParaView3 co -d CMakeBuildForPython -r Python-2_5_1-BRANCH ParaView3/Utilities/CMakeBuildForPython cp -r CMakeBuildForPython/* . cmake . make [...] [ 99%] Building C object CMakeFiles/pythonLib.dir/Modules/xxsubtype.o [100%] Building C object CMakeFiles/pythonLib.dir/Modules/_weakref.o Linking C static library libpython2.5.a [100%] Built target pythonLib Scanning dependencies of target python [100%] Building C object CMakeFiles/python.dir/Modules/python.o Linking C executable python /usr/bin/ld: libpython2.5.a(posixmodule.o): in function posix_tempnam:posixmodule.c(.text+0x4c23): warning: the use of `tempnam' is dangerous, better use `mkstemp' /usr/bin/ld: libpython2.5.a(posixmodule.o): in function posix_tmpnam:posixmodule.c(.text+0x4ced): warning: the use of `tmpnam_r' is dangerous, better use `mkstemp' [100%] Built target python Hth Jc On Mon, Jan 2, 2012 at 9:07 PM, Bram Kouwenberg kouwenberg.b...@gmail.comwrote: here s the same message with the screenie as a png -- Forwarded message -- From: Bram Kouwenberg kouwenberg.b...@gmail.com Date: Tue, Jan 3, 2012 at 2:43 AM Subject: Re: [CMake] compiling problem cmake To: Jean-Christophe Fillion-Robin jchris.filli...@kitware.com Cc: cmake@cmake.org the python source i got from http://python.org/ftp/python/2.5.6/ the directions I followed were mainly from http://www.vtk.org/Wiki/BuildingPythonWithCMake#Building_Python_for_Linux_or_Windows were I took the 251 snapshot and changed the patch number to 6. Then during configuring I had to manually indicate some modules and env variables, up until this error appeared. let me know if you need know more On Tue, Jan 3, 2012 at 12:53 AM, Jean-Christophe Fillion-Robin jchris.filli...@kitware.com wrote: Hi Bram, In order to reproduce and understand the problem, would also be great to point us to a repository or place to download the sources. Additionally, could you also mention which version of CMake and which generator you were using ? Hth Jc On Mon, Jan 2, 2012 at 6:30 PM, Bram Kouwenberg kouwenberg.b...@gmail.com wrote: Hi, i want to compile an old python version from source with cmake on win 7 but during this process things go wrong with compiling a test already; below is the error text: there's a proble creating a folder '/cmTryCompileExec/fast' in CmakeTmp. I don't now why. the only strange thing is in explorer I see the following tree: C:\python256\CMakeFiles\CMakeTmp\CMakeFiles\cmTryCompileExec.dir it seems the config process creates another Cmakefiles folder. I have no clue why since I'm not familiar with configuring/compiling, but it might explain why this TryCompilefast folder cannot be created. Anybody see what the problem is here? tnx The C compiler identification is GNU The CXX compiler identification is GNU Found Eclipse version 4.1 () Check for working C compiler: C:/MinGW32/bin/gcc.exe Check for working C compiler: C:/MinGW32/bin/gcc.exe -- broken CMake Error at C:/Program Files/CMake 2.8/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:52 (MESSAGE): The C compiler C:/MinGW32/bin/gcc.exe is not able to compile a simple test program. It fails with the following output: Change Dir: C:/python256/CMakeFiles/CMakeTmp Run Build Command:C:/PROGRA~1/CMAKE2~1.8/bin/cmake.exe cmTryCompileExec/fast CMake Error: The source directory C:/python256/CMakeFiles/CMakeTmp/cmTryCompileExec/fast does not exist. Specify --help for usage, or press the help button on the CMake GUI. CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:3 (project) Configuring incomplete, errors occurred! -- 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://www.cmake.org/mailman/listinfo/cmake -- +1 919 869 8849 -- +1 919 869 8849 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Running coverage analysis
To actually run the coverage testing, you need to have tests added with add_test in your CMakeLists file, then you need to run a ctest -S script that calls ctest_coverage, or use one of the predefined coverage dashboard targets. (Use 'make help | grep Coverage' to see those.) On Jan 2, 2012, at 9:21 PM, David Doria daviddo...@gmail.com wrote: I found this wiki page: http://www.vtk.org/Wiki/CTest/Coverage#Coverage_With_C.2B.2B that explains the flags that are necessary. I set up a demo project here and it compiles: http://www.vtk.org/Wiki/CTest/Coverage/Example However, how do you actually run the coverage analysis? I ran 'ctest' but there are no magic tests that were setup. Are there more instructions somewhereon performing and viewing the coverage? Thanks, David -- 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://www.cmake.org/mailman/listinfo/cmake -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Running coverage analysis
On Tue, Jan 3, 2012 at 9:52 AM, David Cole david.c...@kitware.com wrote: To actually run the coverage testing, you need to have tests added with add_test in your CMakeLists file, then you need to run a ctest -S script that calls ctest_coverage, or use one of the predefined coverage dashboard targets. (Use 'make help | grep Coverage' to see those.) When I run 'make help' from that example project's build dir I just see doriad@david-lab:~/build/Examples/CTest/Coverage$ make help The following are some of the valid targets for this Makefile: ... all (the default if no target is provided) ... clean ... depend ... Coverage ... edit_cache ... rebuild_cache ... test ... coverage.o ... coverage.i ... coverage.s I also ran 'make help | grep Coverage' in the VTK build dir (because I'd assume the dashboard targets you're talking about would be in a big project like VTK) but there is no output. Are these dashboard targets project specific? That is, if I'm working on a project that does not have a dashboard server, how would you see the coverage report? It'd be great if someone could add a simple example script that calls ctest_coverage to this example, along with the procedure to run it and inspect the result: http://www.cmake.org/Wiki/CTest/Coverage/Example David -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Running coverage analysis
The way I have always approached problems like this is to check out what existing scripts are doing that are already successfully submitting coverage results. This one is on the VTK dashboard: http://cdash.org/CDash/viewNotes.php?buildid=1880030 This one on CMake: http://cdash.org/CDash/viewNotes.php?buildid=1879840 This one on ITK: http://cdash.org/CDash/viewNotes.php?buildid=1879940 A simplest minimal example script that works with your example project should be fairly easy to derive by distilling the coverage-related elements from those scripts. I think there's also a script in the ITK source tree that helps you run coverage on just your own test and inspect the results locally. I can't remember its whereabouts, but I bet you could find that too if you search the ITK list archives. It'd be great if someone could add a simple example script that calls ctest_coverage to this example, along with the procedure to run it and inspect the result: http://www.cmake.org/Wiki/CTest/Coverage/Example I agree. That would be great. Hopefully, this is helpful, for now. David C. On Tue, Jan 3, 2012 at 10:18 AM, David Doria daviddo...@gmail.com wrote: On Tue, Jan 3, 2012 at 9:52 AM, David Cole david.c...@kitware.com wrote: To actually run the coverage testing, you need to have tests added with add_test in your CMakeLists file, then you need to run a ctest -S script that calls ctest_coverage, or use one of the predefined coverage dashboard targets. (Use 'make help | grep Coverage' to see those.) When I run 'make help' from that example project's build dir I just see doriad@david-lab:~/build/Examples/CTest/Coverage$ make help The following are some of the valid targets for this Makefile: ... all (the default if no target is provided) ... clean ... depend ... Coverage ... edit_cache ... rebuild_cache ... test ... coverage.o ... coverage.i ... coverage.s I also ran 'make help | grep Coverage' in the VTK build dir (because I'd assume the dashboard targets you're talking about would be in a big project like VTK) but there is no output. Are these dashboard targets project specific? That is, if I'm working on a project that does not have a dashboard server, how would you see the coverage report? It'd be great if someone could add a simple example script that calls ctest_coverage to this example, along with the procedure to run it and inspect the result: http://www.cmake.org/Wiki/CTest/Coverage/Example David -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Wiki: version compatibility matrix
The Cite extension is now installed on the CMake wiki. See this page to see what mediawiki extensions are available: http://www.cmake.org/Wiki/Special:Version HTH, David On Mon, Jan 2, 2012 at 12:03 PM, Johannes Zarl johannes.z...@jku.at wrote: Hi David, I guess I'll have time this week to update the matrix. In case the admin team would like to have a rationale for installing the Cite extension: Having the Cite extension would allow me to write the matrix in a more compact/less cluttered style. Thanks for lobbying for this issue! Johannes On Monday, 2. January 2012, 16:33:04, David Cole wrote: Hi Johannes, Time to update again, this time for CMake 2.8.7. This page tells me what the Cite extension is: http://www.mediawiki.org/wiki/Extension:Cite This page tells me it's not installed yet on the CMake wiki server: http://www.cmake.org/Wiki/Special:Version I'll ask the admin team to install it. I'll let you know if they say we can't for some reason... -- 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://www.cmake.org/mailman/listinfo/cmake -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] compiling problem cmake
hi, thnx for helping. interesting to see you use the 251 cmake unaltered for 256 and it works. I guess the path building problem is a mingw thing indeed. why would it create another CMakeFiles in CMakeTmp? Where can I find the script that prescribes this? I just added a screenie of explorer and the cmake error log. le me know if this brings to you some fresh idea's On Tue, Jan 3, 2012 at 3:07 AM, Bram Kouwenberg kouwenberg.b...@gmail.comwrote: here s the same message with the screenie as a png -- Forwarded message -- From: Bram Kouwenberg kouwenberg.b...@gmail.com Date: Tue, Jan 3, 2012 at 2:43 AM Subject: Re: [CMake] compiling problem cmake To: Jean-Christophe Fillion-Robin jchris.filli...@kitware.com Cc: cmake@cmake.org the python source i got from http://python.org/ftp/python/2.5.6/ the directions I followed were mainly from http://www.vtk.org/Wiki/BuildingPythonWithCMake#Building_Python_for_Linux_or_Windows were I took the 251 snapshot and changed the patch number to 6. Then during configuring I had to manually indicate some modules and env variables, up until this error appeared. let me know if you need know more On Tue, Jan 3, 2012 at 12:53 AM, Jean-Christophe Fillion-Robin jchris.filli...@kitware.com wrote: Hi Bram, In order to reproduce and understand the problem, would also be great to point us to a repository or place to download the sources. Additionally, could you also mention which version of CMake and which generator you were using ? Hth Jc On Mon, Jan 2, 2012 at 6:30 PM, Bram Kouwenberg kouwenberg.b...@gmail.com wrote: Hi, i want to compile an old python version from source with cmake on win 7 but during this process things go wrong with compiling a test already; below is the error text: there's a proble creating a folder '/cmTryCompileExec/fast' in CmakeTmp. I don't now why. the only strange thing is in explorer I see the following tree: C:\python256\CMakeFiles\CMakeTmp\CMakeFiles\cmTryCompileExec.dir it seems the config process creates another Cmakefiles folder. I have no clue why since I'm not familiar with configuring/compiling, but it might explain why this TryCompilefast folder cannot be created. Anybody see what the problem is here? tnx The C compiler identification is GNU The CXX compiler identification is GNU Found Eclipse version 4.1 () Check for working C compiler: C:/MinGW32/bin/gcc.exe Check for working C compiler: C:/MinGW32/bin/gcc.exe -- broken CMake Error at C:/Program Files/CMake 2.8/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:52 (MESSAGE): The C compiler C:/MinGW32/bin/gcc.exe is not able to compile a simple test program. It fails with the following output: Change Dir: C:/python256/CMakeFiles/CMakeTmp Run Build Command:C:/PROGRA~1/CMAKE2~1.8/bin/cmake.exe cmTryCompileExec/fast CMake Error: The source directory C:/python256/CMakeFiles/CMakeTmp/cmTryCompileExec/fast does not exist. Specify --help for usage, or press the help button on the CMake GUI. CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:3 (project) Configuring incomplete, errors occurred! -- 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://www.cmake.org/mailman/listinfo/cmake -- +1 919 869 8849 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] on find_package and building dependencies
On Thursday 29 December 2011, Eric Noulard wrote: 2011/12/29 Ryan Lewis m...@ryanlewis.net: Hi, I really like CMake's find_package() utility for finding dependencies, but for some projects I have a separate local copy of the installed libraries, and I want to point find_package at a particular directory to find the installed libraries. How can I do this? Have a look at find_package documentation, in particular the usage of CMAKE_FIND_ROOT_PATH and other *CMAKE_FIND_ROOT_PATH_* variables you basically want: set(CMAKE_FIND_ROOT_PATH /you/local/install/dir) before calling find_package(...) No, please don't. CMAKE_FIND_ROOT_PATH is intended for cross-compiling, to tell cmake where the root of the target file system is located. Use CMAKE_PREFIX_PATH instead. It can contain a list of directories, and find_program(), find_file(), find_path(), find_package() and find_library() append bin/, include/ and lib/ respectively to each of the directories listed there. The directories resulting from CMAKE_PREFIX_PATH are checked before all PATHS and HINTS directories. E.g. if you have stuff inside /your/local/install/dir and /some/other/dir, do $ export CMAKE_PREFIX_PATH=/your/local/install/dir:/some/other/dir $ cmake ...args or set it directly as a cmake variable within your CMakeLists.txt. 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] on find_package and building dependencies
2012/1/3 Alexander Neundorf a.neundorf-w...@gmx.net: you basically want: set(CMAKE_FIND_ROOT_PATH /you/local/install/dir) before calling find_package(...) No, please don't. CMAKE_FIND_ROOT_PATH is intended for cross-compiling, to tell cmake where the root of the target file system is located. Ok my bad. Sorry Alex (twice in fact) for giving wrong advice concerning this. I wasn't aware of the fact that CMAKE_FIND_ROOT_PATH was **reserved** for cross-compiling. Use CMAKE_PREFIX_PATH instead. It can contain a list of directories, and find_program(), find_file(), find_path(), find_package() and find_library() append bin/, include/ and lib/ respectively to each of the directories listed there. The directories resulting from CMAKE_PREFIX_PATH are checked before all PATHS and HINTS directories. E.g. if you have stuff inside /your/local/install/dir and /some/other/dir, do $ export CMAKE_PREFIX_PATH=/your/local/install/dir:/some/other/dir $ cmake ...args or set it directly as a cmake variable within your CMakeLists.txt. Alex -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Bug fix requests for the *next* release of CMake...
Might be nice to decide about this one: http://public.kitware.com/Bug/view.php?id=4756 Sean -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake still broken post-2.8.1
I'm back to this. I never got (or never understood!) an answer to this part of the thread, which is where the breakage occurred: -- If I comment out line 29 in CMakeDetermineCompilerId.cmake, it works with my old toolchain file, but fails later with the new one, because it appears to call the compiler without the flags, and regina with no arguments produces Help and exits. Why are the semicolons being inserted? If I wanted semicolons between the parameters, why wouldn't I just specify them? Brad, your comment in the thread says: Teach compiler identification to support values such as export CC='gcc -g -O2' by separating the arguments on spaces. Not sure what on spaces means, but again, it seems wrong to me that anything is messing with my option format. -- So -- why are semicolons being inserted? ...phsiii -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Bug fix requests for the *next* release of CMake...
http://public.kitware.com/Bug/view.php?id=8438 http://public.kitware.com/Bug/view.php?id=11258 David. -- 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://www.cmake.org/mailman/listinfo/cmake
[CMake] Incorrect implicit library selections in generated link statements
I have a large static library comprised of C, C++, Fortran, and Ada source files. I have a number of C, C++, Fortran, and Ada executables linking against this library. When CMake generates the link statements in link.txt, the implicit libraries selected to be linked against from the possibilities located in CMakeFiles/CMake[lang]Compiler.cmake are always incorrect. For example, in an Ada executable, the implicit libraries selected to be linked against are only C and Fortran, not Ada, and some of the libraries selected are superfluous while other necessary libraries are not included at all. Also, the directory where the Fortran libraries are found is not pulled from the implicit link directory possibilities, whereas the C one is. For a Fortran executable, the libraries selected to be linked against are found from C, Fortran, C++, and Ada, but once again the library selection seems random and the directory containing the Ada libraries is absent from the link statement. This is especially disconcerting since those libraries are in /usr/lib[64]. Why is CMake's link statement logic regarding implicit libraries completely imploding when executables link against a static library comprised of multiple languages? Does anyone know of some good hacks/kludges to circumvent CMake's behavior? -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Incorrect implicit library selections in generated link statements
On Tue, Jan 3, 2012 at 2:30 PM, Schuchard, Matthew matthew.schuch...@gtri.gatech.edu wrote: I have a large static library comprised of C, C++, Fortran, and Ada source files. I have a number of C, C++, Fortran, and Ada executables linking against this library. When CMake generates the link statements in link.txt, the implicit libraries selected to be linked against from the possibilities located in CMakeFiles/CMake[lang]Compiler.cmake are always incorrect. For example, in an Ada executable, the implicit libraries selected to be linked against are only C and Fortran, not Ada, and some of the libraries selected are superfluous while other necessary libraries are not included at all. Also, the directory where the Fortran libraries are found is not pulled from the implicit link directory possibilities, whereas the C one is. For a Fortran executable, the libraries selected to be linked against are found from C, Fortran, C++, and Ada, but once again the library selection seems random and the directory containing the Ada libraries is absent from the link statement. This is especially disconcerting since those libraries are in /usr/lib[64]. Why is CMake’s link statement logic regarding implicit libraries completely imploding when executables link against a static library comprised of multiple languages? Does anyone know of some good hacks/kludges to circumvent CMake’s behavior? -- 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://www.cmake.org/mailman/listinfo/cmake How did you build your large static library comprised of C, C++, Fortran, and Ada source files ... ? (Just curious, and suspect the answer may help others answer your question, too.) -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Bug fix requests for the *next* release of CMake...
On Monday 02 January 2012, David Cole wrote: Hi all, Replies requested. Short replies only. Read on. Just a short reply with bug numbers or links to the bugs is all we need here. Please move specific discussions into the bugs themselves or start a new thread to talk about it... Replies on this thread should just be a collector for bug numbers. If I may ;-) : http://public.kitware.com/Bug/view.php?id=11536 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Bug fix requests for the *next* release of CMake...
http://public.kitware.com/Bug/view.php?id=12652 -- 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://www.cmake.org/mailman/listinfo/cmake
[CMake] CPack - Windows 7 x64
Hi, I am building and installing full 64bit applications and libraries. When I package it up as an installer via NSIS, it installs to C:\Program Files (x86)\ What CPACK_ variables do I need to inform cpack that it should be installed in C:\Program Files\ Regards -- Nicholas Yue Graphics - RenderMan, Houdini, Visualization, OpenGL, HDF5 Custom Dev - C++ porting, OSX, Linux, Windows http://au.linkedin.com/in/nicholasyue -- 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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack - Windows 7 x64
On Tue, Jan 3, 2012 at 8:05 PM, Nicholas Yue yue.nicho...@gmail.com wrote:
Hi,
I am building and installing full 64bit applications and libraries.
When I package it up as an installer via NSIS, it installs to C:\Program
Files (x86)\
What CPACK_ variables do I need to inform cpack that it should be
installed in C:\Program Files\
Regards
--
Nicholas Yue
Graphics - RenderMan, Houdini, Visualization, OpenGL, HDF5
Custom Dev - C++ porting, OSX, Linux, Windows
http://au.linkedin.com/in/nicholasyue
--
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://www.cmake.org/mailman/listinfo/cmake
What version of CMake/CPack are you using?
As long as it's recent enough (2.8.4 or later), you can use code like
this, which CMake itself uses:
(from the CMake source tree, top level, file CMakeCPack.cmake)
# Installers for 32- vs. 64-bit CMake:
# - Root install directory (displayed to end user at installer-run time)
# - NSIS package/display name (text used in the installer GUI)
# - Registry key used to store info about the installation
IF(CMAKE_CL_64)
SET(CPACK_NSIS_INSTALL_ROOT $PROGRAMFILES64)
SET(CPACK_NSIS_PACKAGE_NAME ${CPACK_PACKAGE_INSTALL_DIRECTORY} (Win64))
SET(CPACK_PACKAGE_INSTALL_REGISTRY_KEY ${CPACK_PACKAGE_NAME}
${CPACK_PACKAGE_VERSION} (Win64))
ELSE()
SET(CPACK_NSIS_INSTALL_ROOT $PROGRAMFILES)
SET(CPACK_NSIS_PACKAGE_NAME ${CPACK_PACKAGE_INSTALL_DIRECTORY})
SET(CPACK_PACKAGE_INSTALL_REGISTRY_KEY ${CPACK_PACKAGE_NAME}
${CPACK_PACKAGE_VERSION})
ENDIF()
The main line to answer your direct question is:
SET(CPACK_NSIS_INSTALL_ROOT $PROGRAMFILES64)
This literal string gets used in the NSIS input, and then it is the
one that interprets that as C:\Program Files on a Win64
installation.
Just do something like that before including CPack, and it should do the trick.
HTH,
David
--
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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack - Windows 7 x64
On Tue, Jan 3, 2012 at 8:05 PM, Nicholas Yue yue.nicho...@gmail.com wrote: Hi, I am building and installing full 64bit applications and libraries. When I package it up as an installer via NSIS, it installs to C:\Program Files (x86)\ What CPACK_ variables do I need to inform cpack that it should be installed in C:\Program Files\ I have had this problem for over a year (with CMake versions up to 2.8.7) although I have not spent much effort trying to fix it. Tomorrow I will try the fix from David and report if that fixes the issue for me. John -- 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://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake annotated tag, v2.8.7, created. v2.8.7
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The annotated tag, v2.8.7 has been created at 2e974af269a523a8ffa1d5251061c7a5a81dadcc (tag) tagging 7f8f6dbf45aa5250281c7e383e3d32599590564b (commit) replaces v2.8.6 tagged by Brad King on Tue Jan 3 09:18:07 2012 -0500 - Log - CMake 2.8.7 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAABAgAGBQJPAw4lAAoJEOyP7zp7+07ac3IP/3lv8clzfFXaCA2depGnDsKN 2+TlRpZKEodNjl7QYZbe0QxBYQyCbkHwQ9QHxbmzmsekPwn7w1qsPPFA63hb5C7g N0mX7UqZhZI/jRYmX1/v0msJ3w8f4Mtg0tITI6eCCga7440uy8KDNzDdEsrtY5Iq AjlJ/0aJhYRb5utwhAknlgmkvU0CBK5npp5NLsuPU8B9IWckDKqxOcsyAg5BcAtZ 2vsxdOSYNu3wV25X7+vu6+/CKDQCHH4YLy9mrjCvalX/puEEuWLIk0gmkLJA75fE Sax33M+GRVlx9lhQsLfu40wLuqx2DxWEKUxJLEvSAknGrx1vlSBLRdITu0W8sUsA iIcIba9BlNZRrpIliVptvc70ZZLgxhqqAyw+mXqxETaePByvuv1vsNZkdLwJWuIy usSxTR73Qjt3Pkq3lSgWZmdU7/WIFJ6XW+be0r7gtKHh662ZXH1EdKRj03rIWoJa 3wlha9tFVSBeEfBGD/kaRCklN6kKWvagRLgsa4x+jZLRPhTlsgUWTMPxJAej6IBE hciiKDyZTnm7p9TZvmX0yigtAmp8FbcLlvbByLQitIikw5CXrvKjSsmXq/LzoaTT ZDP6c6S0Pu+FXxbhJfmYWNq8nZB6r39JI52/FYhxKg7EQMN/g9MEh54L4aLkw6N6 /cbMO1LZGebMZBEvMzdd =Fc+e -END PGP SIGNATURE- Aaron Ten Clay (1): VS: Add support for three new project properties (#12586) Alex Neundorf (65): fix #12392: handle CMAKE_CXX_COMPILER_ARG1 for Eclipse projects fix #12262: use the C dependency scanner also for ASM files fix #12465: detect the masm compiler ID (MSVC) Silence make on OpenBSD in FindPackageModeTest(#12508) Remove trailing whitespace Find Ruby on OpenBSD when installed from ports (#12507) Eclipse generator: detect Eclipse version Detect whether the current Eclipse version supports VirtualFolders Eclipse: don't create VirtualFolders if not supported Eclipse: better message when Eclipse version could not be determined Eclipse: add virtual folder for each target automoc:run moc on the header if the source file contains include foo.moc Add copyright notices automoc: always run moc on the cpp file if there is a foo.moc included Eclipse: move code for generating links to projects into separate function Eclipse: move code for generating links to targets into separate function Eclipse: add Build and Clean targets to targets Eclipse: detect number of CPUs, set CMAKE_ECLIPSE_MAKE_ARGUMENTS accordigly Eclipse: fix #12417, don't create wrong src pathentries FindLibXslt: also search libexslt and xsltproc don't crash in automoc with empty COMPILE_DEFINITIONS property Eclipse: make targets work from any directory Automoc: fix the fix, need to use std::string, not just char* pointer automoc: fix #12541, support moc options add documentation for the AUTOMOC_MOC_OPTIONS property Eclipse: warn if CMAKE_BINARY_DIR is subdir of CMAKE_SOURCE_DIR Eclipse: quote the build dir (to make it work with spaces) make automoc work when using ccmake via PATH (#12551) automoc: stricter checking for what file is included automoc: rework the checking for the matching header, to give better warnings automoc: handle the case when the developer includes the wrong mocfile automoc: add more test cases automoc: improved diagnostics automoc: minor optimization automoc: another runtime optimization Strip trailing whitespace -make GETTEXT_PROCESS_PO_FILES() work with files with multiple dots FindGettext: two more fixes for files with multiple dots Automoc: modified handling of included .moc files FindPNG: provide PNG_INCLUDE_DIRS, as the readme.txt says (#11312) Eclipse: create links to subprojects also in the source-project (#12579) Eclipse: use new variable CMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT Remove trailing whitespace cmake-gui: add completion for the names when adding cache entries automoc: add a test for including both abc.moc and moc_abc.cpp automoc: add test for including the moc file from another header automoc: add test for including a moc_abc_p.cpp file automoc: move some code from the big parsing loop into separate functions install(EXPORT): Enforce existence of imported target files automoc: add special handling for including basename_p.moc, with test automoc: add extra check whether the header contains Q_PRIVATE_SLOT automoc: some more linebreaks for the warnings for better readability automoc: fix handling of included _p.moc files automoc: move the code for finding headers into separate function automoc: add a StrictParseCppFile(), which is only qmake-compatible automoc: also accept other files when .moc is included in non-strict mode automoc: accept even more .moc
[Cmake-commits] CMake branch, next, updated. v2.8.7-1937-g4f132ef
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 4f132efd7d7203a3b725af95a9d2c394386ae611 (commit)
via f15d75760f2041b43f25a6a0b83b59908acf8781 (commit)
from 699849d4ab5c3792330470c0a3c1694be8f73864 (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=4f132efd7d7203a3b725af95a9d2c394386ae611
commit 4f132efd7d7203a3b725af95a9d2c394386ae611
Merge: 699849d f15d757
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Jan 3 11:43:20 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Jan 3 11:43:20 2012 -0500
Merge topic 'update-libarchive' into next
f15d757 libarchive: Remove hard-coded build configuration
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f15d75760f2041b43f25a6a0b83b59908acf8781
commit f15d75760f2041b43f25a6a0b83b59908acf8781
Author: Brad King brad.k...@kitware.com
AuthorDate: Tue Jan 3 11:37:32 2012 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Tue Jan 3 11:37:32 2012 -0500
libarchive: Remove hard-coded build configuration
Do not set CMAKE_BUILD_TYPE to Debug. Use the configuration specified by
the user.
diff --git a/Utilities/cmlibarchive/CMakeLists.txt
b/Utilities/cmlibarchive/CMakeLists.txt
index f341bf2..100c12f 100644
--- a/Utilities/cmlibarchive/CMakeLists.txt
+++ b/Utilities/cmlibarchive/CMakeLists.txt
@@ -7,7 +7,6 @@ SET(CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/build/cmake)
if(NOT CMAKE_RUNTIME_OUTPUT_DIRECTORY)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${libarchive_BINARY_DIR}/bin)
endif()
-SET(CMAKE_BUILD_TYPE Debug)
# On MacOS, prefer MacPorts libraries to system libraries.
# I haven't come up with a compelling argument for this to be conditional.
---
Summary of changes:
Utilities/cmlibarchive/CMakeLists.txt |1 -
1 files changed, 0 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.7-1944-g835d6f3
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 835d6f3e2d8fea1d1c7f4179f362235d1e5d4d8d (commit)
via d2c9626d5a2859a410dfed32fd1d55e1d386562c (commit)
from 8bceb01217b735dc924a251cab8ea7ece47eab29 (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=835d6f3e2d8fea1d1c7f4179f362235d1e5d4d8d
commit 835d6f3e2d8fea1d1c7f4179f362235d1e5d4d8d
Merge: 8bceb01 d2c9626
Author: Eric Noulard eric.noul...@gmail.com
AuthorDate: Tue Jan 3 12:04:56 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Jan 3 12:04:56 2012 -0500
Merge topic 'ImproveCPackDoc-part1' into next
d2c9626 Document undocumented (but existing) cpack options (fix #0010134)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d2c9626d5a2859a410dfed32fd1d55e1d386562c
commit d2c9626d5a2859a410dfed32fd1d55e1d386562c
Author: Eric NOULARD eric.noul...@gmail.com
AuthorDate: Sat Nov 5 14:41:23 2011 +0100
Commit: Eric NOULARD eric.noul...@gmail.com
CommitDate: Tue Jan 3 16:47:35 2012 +0100
Document undocumented (but existing) cpack options (fix #0010134)
diff --git a/Source/CPack/cpack.cxx b/Source/CPack/cpack.cxx
index b1706e3..163f744 100644
--- a/Source/CPack/cpack.cxx
+++ b/Source/CPack/cpack.cxx
@@ -71,6 +71,25 @@ static const char * cmDocumentationOptions[][3] =
{--config config file, Specify the config file.,
Specify the config file to use to create the package. By default
CPackConfig.cmake in the current directory will be used. },
+{--verbose,-V,enable verbose output,Run cpack with verbose output.},
+{--debug,enable debug output (for CPack developers),
+ Run cpack with debug output (for CPack developers).},
+{-P package name,override/define CPACK_PACKAGE_NAME,
+ If the package name is not specified on cpack commmand line then
+ CPack.cmake defines it as CMAKE_PROJECT_NAME},
+{-R package version,override/define CPACK_PACKAGE_VERSION,
+ If version is not specified on cpack command line then
+ CPack.cmake defines it from CPACK_PACKAGE_VERSION_[MAJOR|MINOR|PATCH]
+ look into CPack.cmake for detail},
+{-B package directory,override/define CPACK_PACKAGE_DIRECTORY,
+ The directory where CPack will be doing its packaging work.
+ The resulting package will be found there. Inside this directory
+ CPack creates '_CPack_Packages' sub-directory which is the
+ CPack temporary directory.},
+{--vendor vendor name,override/define CPACK_PACKAGE_VENDOR,
+ If vendor is not specified on cpack command line
+ (or inside CMakeLists.txt) then
+ CPack.cmake defines it with a default value},
{0,0,0}
};
@@ -440,6 +459,10 @@ int main (int argc, char *argv[])
}
}
+ /* In this case we are building the documentation object
+ * instance in order to create appropriate structure
+ * in order to satisfy the appropriate --help-xxx request
+ */
if ( help )
{
doc.CheckOptions(argc, argv);
---
Summary of changes:
Source/CPack/cpack.cxx | 23 +++
1 files changed, 23 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.7-1947-g0da55e0
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 0da55e05a9e6aabcf806f2fb0c79465c5ffbf5e7 (commit)
via 4d253d1a9d9ec3b3a1f38cb2a490da998f88482a (commit)
via df224727cfcc233fbe36417e48f2e5fee01c73ee (commit)
from 835d6f3e2d8fea1d1c7f4179f362235d1e5d4d8d (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=0da55e05a9e6aabcf806f2fb0c79465c5ffbf5e7
commit 0da55e05a9e6aabcf806f2fb0c79465c5ffbf5e7
Merge: 835d6f3 4d253d1
Author: Eric Noulard eric.noul...@gmail.com
AuthorDate: Tue Jan 3 12:15:46 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Jan 3 12:15:46 2012 -0500
Merge topic 'CMake-bash-completion-enhance' into next
4d253d1 Enhance bash completion file for cmake and ctest
df22472 KWSys Nightly Date Stamp
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4d253d1a9d9ec3b3a1f38cb2a490da998f88482a
commit 4d253d1a9d9ec3b3a1f38cb2a490da998f88482a
Author: Eric NOULARD eric.noul...@gmail.com
AuthorDate: Tue Jan 3 18:12:56 2012 +0100
Commit: Eric NOULARD eric.noul...@gmail.com
CommitDate: Tue Jan 3 18:12:56 2012 +0100
Enhance bash completion file for cmake and ctest
- filter out cmake/ctest version line
- provide -R as -E completion with ctest
diff --git a/Docs/cmake-completion b/Docs/cmake-completion
index 011f3fa..d82d608 100644
--- a/Docs/cmake-completion
+++ b/Docs/cmake-completion
@@ -51,13 +51,20 @@ _cmake()
COMPREPLY=( $(compgen -W ${running} -- ${cur}) )
return 0
;;
+# FIXME: don't know how to handle multi words completion
+# or more precisely word that contains space in them like Unix
Makefiles
+ # -G)
+# local running=$(for x in `cmake --help | grep ^ .*=\ .* |
grep -v ^ - | cut -d= -f 1 | grep -v ^ `; do echo \${x}\ ; done )
+# COMPREPLY=( $(compgen -W ${running} -- ${cur}) )
+# return 0
+# ;;
--help-command)
-local running=$(for x in `cmake --help-command-list`; do echo ${x}
; done )
+local running=$(for x in `cmake --help-command-list | grep -v
cmake version`; do echo ${x} ; done )
COMPREPLY=( $(compgen -W ${running} -- ${cur}) )
return 0
;;
--help-module)
-local running=$(for x in `cmake --help-module-list`; do echo ${x}
; done )
+local running=$(for x in `cmake --help-module-list | grep -v
cmake version`; do echo ${x} ; done )
COMPREPLY=( $(compgen -W ${running} -- ${cur}) )
return 0
;;
@@ -67,12 +74,12 @@ _cmake()
return 0
;;
--help-property)
-local running=$(for x in `cmake --help-property-list`; do echo
${x} ; done )
+local running=$(for x in `cmake --help-property-list | grep -v
cmake version`; do echo ${x} ; done )
COMPREPLY=( $(compgen -W ${running} -- ${cur}) )
return 0
;;
--help-variable)
-local running=$(for x in `cmake --help-variable-list`; do echo
${x} ; done )
+local running=$(for x in `cmake --help-variable-list | grep -v
cmake version`; do echo ${x} ; done )
COMPREPLY=( $(compgen -W ${running} -- ${cur}) )
return 0
;;
@@ -128,14 +135,14 @@ _cpack()
esac
#
-# Complete the option (Level 0 - right after cmake)
+# Complete the option (Level 0 - right after cpack)
#
COMPREPLY=( $(compgen -W ${opts} -- ${cur}) )
}
complete -F _cpack -o default cpack
#
-# cmake command
+# ctest command
#
# have ctest
_ctest()
@@ -156,11 +163,11 @@ _ctest()
#
case ${prev} in
--help-command)
-local running=$(for x in `ctest --help-command-list`; do echo ${x}
; done )
+local running=$(for x in `ctest --help-command-list | grep -v
ctest version `; do echo ${x} ; done )
COMPREPLY=( $(compgen -W ${running} -- ${cur}) )
return 0
;;
--R)
+-R|-E)
local running=$(for x in `ctest -N 2 /dev/null | grep ^ Test |
cut -d: -f 2`; do echo ${x} ; done )
COMPREPLY=( $(compgen -W ${running} -- ${cur}) )
return 0
@@ -187,4 +194,4 @@ complete -F _ctest -o default ctest
# sh-indent-comment: t
# indent-tabs-mode: nil
# End:
-# ex: ts=4 sw=4 et filetype=sh
\ No newline at end of file
+# ex: ts=4 sw=4 et filetype=sh
---
Summary of changes:
Docs/cmake-completion
[Cmake-commits] CMake branch, next, updated. v2.8.7-1951-g1359324
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 135932415b3de7975a6fc90606b04b9e0471523d (commit) via 27bc9e2631a2f7b6d78064f5adf0b528982a2de7 (commit) from af18e7643ed2be76678080b9e543a575bafd32fa (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=135932415b3de7975a6fc90606b04b9e0471523d commit 135932415b3de7975a6fc90606b04b9e0471523d Merge: af18e76 27bc9e2 Author: Philip Lowman phi...@yhbt.com AuthorDate: Tue Jan 3 19:51:43 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Jan 3 19:51:43 2012 -0500 Merge topic 'FindProtobuf_import_dirs' into next 27bc9e2 FindProtobuf: Update documentation comment for 2.8.8 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=27bc9e2631a2f7b6d78064f5adf0b528982a2de7 commit 27bc9e2631a2f7b6d78064f5adf0b528982a2de7 Author: Philip Lowman phi...@yhbt.com AuthorDate: Tue Jan 3 19:47:05 2012 -0500 Commit: Philip Lowman phi...@yhbt.com CommitDate: Tue Jan 3 19:47:05 2012 -0500 FindProtobuf: Update documentation comment for 2.8.8 diff --git a/Modules/FindProtobuf.cmake b/Modules/FindProtobuf.cmake index ac6fd86..1e1e493 100644 --- a/Modules/FindProtobuf.cmake +++ b/Modules/FindProtobuf.cmake @@ -8,7 +8,7 @@ # for libraries and binaries. # # PROTOBUF_IMPORT_DIRS - List of additional directories to be searched for -# imported .proto files. (New in CMake 2.8.7) +# imported .proto files. (New in CMake 2.8.8) # # Defines the following variables: # --- Summary of changes: Modules/FindProtobuf.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
