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

[Andreas Mohr]

Hi,

On Sun, Jul 17, 2011 at 11:16:56PM +0200, Daniel Franke wrote:
> > 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?

Well, my particular installation here in fact has that kind of handling,
for "historical" (not necessarily good...) reasons.

My statement was supposed to apply to CPack.cmake configuration parts only
(and as has been said by Eric Noulard, this kind of global handling as
currently provided by CMake is not optimal).
install() things should ideally be done within local tool locations I'd
think.

> 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 ...

WOW, those numbers sound quite excessive.
Here, I've got some 55 projects, some 493 targets (make help|wc -l),
perhaps 600MB of binary install,
and a configure run takes perhaps 15 seconds to complete, and an empty
build around 15 seconds to analyze all targets
(perhaps due to that unfortunate non-'non-recursive' make environment
as setup by CMake for non-GNU make compatibility reasons).
[numbers as running on Core2Duo, Makefile generator]

My configure-time handling has been optimized quite well, though
(all things pushed into build-time actions as much as possible).

OTOH your setup may very well be orders of magnitude bigger than mine
(perhaps many more small targets), which could explain the difference.

Andreas Mohr