[cmake-developers] Improving CPack Documentation (and may be others as well)
Eric Noulard
eric.noulard at gmail.com
Tue Jan 3 11:45:38 EST 2012
2012/1/3 Brad King <brad.king at 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.noulard at gmail.com>
Date: Sun Nov 13 22:47:25 2011 +0100
Update cmake bash completion file.
commit 1e38d6dd306522a0d08355a6c7ef57293b46b5a6
Author: Eric NOULARD <eric.noulard at 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.noulard at 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
More information about the cmake-developers
mailing list