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

[Daniel Franke]

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.


> 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, as all are 
installed in their respective definition file. With this scheme, I can be 
somewhat confident that anyone can take a CMakeLists.txt file from an existing 
directory and use it as a template for a new tool and things "Just Work" (TM). 

If this is contrary to how the rest of the world uses cmake, is there a 
tutorial on "How to properly set up large scale CMake projects that are still 
usable and extendable by people not concerning themselves with the build 
system"? ;)


> Thinking more about it,  it seems you're trying hard to have a nicely
> hierarchical setup of all your components, and this is perhaps the problem:
> each sub component should ideally be fully standalone (and merely be
> _global-governed_ by the containing project),
> and thus have its own packaging as well (i.e., by including CPack setup).

Given the technical simplicity of the tools in question, defining a self-
contained project for each would probably be overkill. The cmake setup is 
meant to reduce overhead, not increase it ...


> > P.S. On my machine it takes 20 minutes to repackage the project, testing
> > even the simplest changes is not fun :(
> 
> Yeah, here I'm experiencing >> 5 mins or so for repackaging (non-NSIS).
> On UNIX restricting CPack generator to TGZ or restricting the COMPONENT:s
> to be installed helps.
> --> you should try aggressively to figure out some methods (via
> option()s or some such) to reduce the amount of packaging activity being
> done for test purposes.

The packaging is only part of it. Regenerating the build files and dependency 
checking after a change already take up 8-12 minutes of this. The actual 
packaging doesn't take that long then. However, yes, I should set up a smaller 
test project for this stuff ...

Thanks for the input!

	Daniel