[CMake] CPack/NSIS: start menu entry without cpack_package_executables

[Eric Noulard]

2011/7/17 Daniel Franke <franke.daniel at gmail.com>:
>
> Hi Andreas.
>
> On Sunday 17 July 2011 21:36:26 Andreas Mohr wrote:
>> to me it sounds like all the effects can simply be described as
>> happening due to including CPack way too early.
>> Verdict: Don't Do That (tm)
>
> Maybe. See below for more details.

There exists several cases where the single & monolithical "include(CPack)"
thing is problematic. have a look at this feature request and related bugs:
http://public.kitware.com/Bug/view.php?id=11808
The main problem with the current "include(CPack)" is that it works
like a one-shot function call.

I began to split CPack.cmake file in more manageable parts during 2.8.4-->2.8.5:
http://cmake.org/gitweb?p=cmake.git;a=commit;h=4bb79402e8f4e5c9c01637f70ca9e4d7b682473b
but this is clearly a work-in-progress. (not currently progressing
because of lack of time)
However it may already useful in your case... see below.

>> IMHO install stuff is ideally (i.e., usually) supposed to be done
>> _exactly after_ all targets within the build space have become available.
>
> How so? Let there be tool01 to toolNN. Let each tool reside in its own
> directory. Each directory has exactly one CMakeLists.txt file. Each
> CMakeLists.txt adds one or more targets that, grouped together, make toolKK.
>
> In your scenario, there would be one, possibly the toplevel, CMakeLists.txt
> that knows all the tools, all its targets and does the installation? And one
> for the packaging? So whenever one adds another toolN+1, one has to hunt down
> all the places to add install and packaging entries instead of keeping that
> together tool-wise in a single CMakeLists.txt in the toolN+1 subdirectory?
>
>
>> I'm currently at a loss why the simple
>> include(CPack)
>> line cannot be done at the very end of the parsing
>> of the entire sub build space in your CMakeLists.txt files hierarchy,
>> but perhaps I'm missing the obvious...  (you seem to point to having moved
>> things into macros/functions as being the reason for the CPack ordering
>> issue, but I don't think that thatis a problem)
>
> Maybe I should have provided an example. At 3am, things start to get fuzzy
> around the edges ...
>
> I defined a bunch of macros, e.g.
>
>    myproject_add_executable()
> and
>    myproject_install_target()
>
> that do what you'd think they should do but also keep track of proper include
> and link directories, dependencies etc and in the latter case, if the proper
> arguments and options are passed, add a component for the installer via
> cpack_add_component(). Example:
>
>    myproject_add_executable(foo SOURCES foo.c foo.h
>                                 LIBRARIES bar)
>    myproject_install_target(TARGETS foo
>                             COMPONENT "foo"
>                             COMPONENT_DESCRIPTION "..."
>                             COMPONENT_GROUP "gui")
>
> Here, everything is done in one place -- but this requires that CPack is
> included before the first target is installed, i.e. defined,

Hi,

Could you explain why you need CPack to be included here?

If the requirement comes from the needed definition of "cpack_add_component"
then you can try to do the following:

1) include(CPackComponent) early enough
   in order to get the "cpack_add_component" macro definition you need.

2) Do what you have to do in your local dirs.

3) Define the CPACK_NSIS_xxx var you need in your main CMakeLists.txt
    or even better do that in a separate CPACK_PROJECT_FILE
    http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#Overall_usage_.28common_to_all_generators.29

    then include(CPack) at the latest point in your main CMakeLists.txt



-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org