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

[Andreas Mohr]

Hi,

On Sun, Jul 17, 2011 at 12:00:15PM -0400, cmake-request at cmake.org wrote:
> I try to build a NSIS package for a largish project with many components and a 
> plethora of local and imported binaries. One of the last steps would be to add 
> Start menu entries for the binaries of the selected components [*].

Sounds like a project size similar to mine...

> The problem I face: due to the size of the project, we abstracted away as much 
> of the cmake/cpack details into macros as possible. This includes adding 
> targets and defining components; as is, all aspects of a binary or component 
> are handled in a single CMakeLists.txt and besides dependencies, no knowledge 
> of other elements is shared between CMakeLists.txt files. These macros, as 
> they define targets, are being called after CPack was included. However, to 
> get start menu entries, it seems that all potential start menu elements in 
> CPACK_PACKAGE_EXECUTABLES must be defined _before_ CPack is included. In my 
> case, on inclusion of CPack, I don't know yet which target will be added or 
> imported later due to system setup, how could I possibly provide a list?

I haven't quite thought through all consequences of your description,
but 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)

IMHO install stuff is ideally (i.e., usually)
supposed to be done _exactly after_ all targets within the build space
have become available.

If some predominantly usual handling is not being done in a project,
then I guess I know which side needs fixing... ;)

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 that is a problem)


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).
However, in a large composite project setup
this will cause CPack to be included first-time at a very early time,
probably causing exactly the problems you describe.
If that is indeed the case in your setup, then I cannot offer a lot of
help, other than perhaps having every single sub component offer an option()
or some such (towards higher project layers)
to disable its own definition of CPack parts (but this seems more like a
workaroundish HACK than a clean solution).

On my side, I'm predominantly using vcproj2cmake for most components
(i.e., a rather special setup),
and having only the global project do the CPack dance once,
thus it's probably not comparable.

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

Andreas Mohr