2012/4/3 David Cole <david.c...@kitware.com>:
> On Tue, Apr 3, 2012 at 11:45 AM, Eric Noulard <eric.noul...@gmail.com> wrote:
>> 2012/4/3 Jonatan Wallmander <jona...@vovoid.com>:
>>> Hi,
>>>
>>> I'm on cmake version 2.8.5
>>>
>>> I looked in the changelog and couldn't find this, so here goes:
>>>
>>>
>>> From what I can tell, NSIS with CPACK_PACKAGE_EXECUTABLES and giving
>>> parameters to the executable isn't supported.
>>>
>>> CMakeLists.txt:
>>> set(CPACK_PACKAGE_EXECUTABLES "my_executable -f;My Executable")
>>>
>>> Resulting row in the cpack NSIS cache file:
>>>
>>> CreateShortCut "$SMPROGRAMS\$STARTMENU_FOLDER\My Executable.lnk"
>>> "$INSTDIR\.\my_executable -f.exe"
>>>
>>> I propose 2 possible solutions:
>>>
>>> 1. (best option IMO)
>>>
>>> Add support for a 3rd parameter for flags, like so:
>>> set(CPACK_PACKAGE_EXECUTABLES "my_executable;My Executable;-f")
>>>
>>> Since executables actually CAN have spaces in them, this would be best.
>>
>> The trouble is the "S" of CPACK_PACKAGE_EXECUTABLES means you can
>> currently give something like:
>>
>> set(CPACK_PACKAGE_EXECUTABLES "my_exe1;My Exe1;my_exe2;My Exe2")
>>
>> so that it will be hard to maintain backward compatibility with option1.
>>
>>> 2. (secondary option)
>>> Add support for parsing the executable on spaces, everything after the first
>>> space goes last in the call.
>>>
>>> I.e. set(CPACK_PACKAGE_EXECUTABLES "my_executable -f;My Executable")
>>
>> Then I may suggest a 3rd option
>>
>> set(CPACK_PACKAGE_EXECUTABLES "my_executable;my_executable_ARGS -f;My
>> Executable")
>>
>> that way we can check from the value right after "executable" that
>> ARGS are provided for
>> the preceding executable, so that the new pattern would be:
>>
>> set(CPACK_PACKAGE_EXECUTABLES
>> "<exeName>;[<exeName>_ARGS<space><args>;]<someString>")
>>
>> Beware of the fact that currently NSIS generator is not the only CPack
>> generator that uses
>> CPACK_PACKAGE_EXECUTABLES OSXX11 uses it as well.
>>
>> Moreover the (in-source) code comment seems outdated or partially
>> wrong since ones can read:
>>
>> cmCPackLogger(cmCPackLog::LOG_ERROR,
>> "CPACK_PACKAGE_EXECUTABLES should contain pairs of <executable> and "
>> "<icon name>." << std::endl);
>>
>> AFAIK, there is no "icon" here just the name of the menu entry?
>>
>> --
>> Erk
>> Le gouvernement représentatif n'est pas la démocratie --
>> http://www.le-message.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
>
>
> Correct: "<icon name>" should be "<text displayed near icon in the Start
> menu>"
Hopefully the builtin doc is better than the code comment and error message:
CPACK_PACKAGE_EXECUTABLES
Lists each of the executables and associated text label to be used to
create Start Menu shortcuts.
For example, setting this to the list ccmake;CMake will create a
shortcut named "CMake" that will execute the installed executable
ccmake. Not all CPack generators use it (at least NSIS and OSXX11
do).
>
> But we cannot easily change the meaning of CPACK_PACKAGE_EXECUTABLES.
Yes right, this one seems ill-named.
The best we can do here may be to create a new meaningfull one
and flag this one as "deprecated" but keep it for backward-compatibility reason.
There is no urgency here, but if we were to "extend" this feature may
be beginning
to use a new var would be better.
--
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.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
