[CMake] NSIS, CPACK_PACKAGE_EXECUTABLES and parameters

[Eric Noulard]

2012/4/3 David Cole <david.cole at kitware.com>:
> On Tue, Apr 3, 2012 at 11:45 AM, Eric Noulard <eric.noulard at gmail.com> wrote:
>> 2012/4/3 Jonatan Wallmander <jonatan at 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