View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0009094CMakeCPackpublic2009-06-02 09:422016-06-10 14:30
ReporterKeith Gardner 
Assigned ToKitware Robot 
PlatformOSWindowsOS Version
Product VersionCMake-2-6 
Target VersionFixed in Version 
Summary0009094: NSIS needs to detect 32-bit/64-bit packaging projects
DescriptionCPack needs to detect if an installer that is being made is for a 32-bit machine or a 64-bit machine.

Problems that it solves:
  Preventing the install of a 64-bit project on a 32-bit machine.
  Installs 64-bit projects in the c:\Program Files\ on a 64-bit machine while 32-bit projects continue to install in c:\Program Files (x86)\.
TagsNo tags attached.
Attached Files

related to 0009148closedDavid Cole Cannot change default program installation directory with NSIS generator 
related to 0006363closedDavid Cole CMake 2.4.8 x64 Windows build from sources installs in 32bit directory C:\Program Files (x86)\CMake 

James Bigler (developer)
2009-08-24 19:14

It may or may not be possible without patching NSIS. [^]
Keith Gardner (reporter)
2009-08-25 12:59

You could set CPack to check if the project was compiled in a 32-bit environment or a 64-bit environment and then pass the appropriate PROGRAMFILES variable to the NSIS script. You could assume it will be 32-bit if the no value is passed.
James Bigler (developer)
2009-08-25 17:21

OK, I got this to work with only a couple of changes:

Add this to CPack.cmake somewhere.


Then change the following two lines in


Note that for my installer, only the second changed line seemed to make any difference.
Clinton Stimpson (developer)
2009-08-27 14:23

We also need to add "SetRegView 64" calls or the installer uses the wrong part of the registry for everything.

So how about putting logic in the file instead of adding a configured variable to fix part of it. Maybe use the already defined CPACK_SYSTEM_NAME variable.
James Bigler (developer)
2009-08-27 17:12

Anyone know how to do what clinton suggests? I don't know much about the NSIS syntax beyond setting variables, so it would take me some time to figure out how to do this.
Clinton Stimpson (developer)
2009-08-27 17:34

I'm not an NSIS expert either, but what I tried didn't work and got too complicated.
I ended up copying the template, replacing PROGRAMFILES with PROGRAMFILES64 and sprinkling some "SetRegView 64" calls in each section and function that reads/writes the registry.
Keith Gardner (reporter)
2010-06-23 14:51

What is the status of this bug? It has sat here idle for almost 9 months and has been opened for over a year already.
David Cole (manager)
2011-01-10 10:13

After the fix for the related bug, 0009148, you can now:

to switch the default directory manually...

Stay tuned for a more automatic fix. May or may not get it in for 2.8.4 at this point, but ...... stay tuned.
David Cole (manager)
2011-01-10 14:46

OK... I've reviewed this a little bit today, and here are my observations:

- The default root directory proposed as the install location by the installer is now controllable by the CPACK_NSIS_INSTALL_ROOT variable: see the fix for issue 0009148 for that -- that partially addresses the concerns of this bug

- The installer programs generated by the CPack/NSIS combination, are themselves 32-bit applications. Most of the registry settings written by the installer program regarding "what's installed" should be stored in a reg key that is only meant for the installer program itself, so there should not be a need for SetRegView 64 calls to put things in the "64-bit section of the registry"... (It may be a convenience mechanism so that you can have installers for 32 and 64-bit editions of your app that have the same exact name.) However, I would say, you should simply build an additional bit of string into the project's name such that "x64" or "64-bit Edition" or something shows up in the project name for the 64-bit edition of your installers. That way, it works as-is, and you do not need the SetRegView calls in the NSIS script.

- Can somebody monitoring this issue make comments about where the SetRegView calls should go if we wanted to make the "convenience mechanism" approach fully automatic?

(Regardless, it looks like further changes to fix this issue will not make it in for the CMake 2.8.4 release, and we will have to push it off until later at this point...)
Keith Gardner (reporter)
2011-01-10 15:07

I would say that it should be configurable just like the install directory. There have been times where I needed to programmatically query the registry for where an application has been installed. An example would be for a 64-bit application looking for a 64-bit installed plugin.
David Cole (manager)
2011-01-11 09:54

So would we just conditionally put two calls to "SetRegView 64" (one for install, one for uninstall), that are in effect for the whole time the (un)installer is running?

Have you used this in an override file? Do you know if that would do what you want?

One way to get unique reg keys based on version with existing CMake/CPack would be to override the default value of CPACK_PACKAGE_INSTALL_REGISTRY_KEY:

As you can see, by default it's based solely on the name and version numbers of the package. You could set it similarly but also account for the architecture of the installed thing, and then at least, you could have different reg entries for 32 and 64 bit editions of your app. (I mention this merely as a workaround for now... because.......)

The deadline for getting new features into CMake 2.8.4 has passed. I'm going to unset the "target version" field here and postpone this to a future release.
Keith Gardner (reporter)
2011-01-11 11:00

Putting the conditional calls for "SetRegView 64" sounds like a good solution. The workaround should work for now. Thanks for the quick response.
Richard Shaw (developer)
2015-09-24 16:11

I haven't had time to dig into this but wanted to make sure that any of the proposed fixes work for cross-compiling from linux as well.
Kitware Robot (administrator)
2016-06-10 14:27

Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

 Issue History
Date Modified Username Field Change
2009-06-02 09:42 Keith Gardner New Issue
2009-08-24 19:14 James Bigler Note Added: 0017202
2009-08-25 12:59 Keith Gardner Note Added: 0017209
2009-08-25 17:21 James Bigler Note Added: 0017210
2009-08-27 14:23 Clinton Stimpson Note Added: 0017227
2009-08-27 17:12 James Bigler Note Added: 0017229
2009-08-27 17:34 Clinton Stimpson Note Added: 0017230
2009-09-11 17:30 Bill Hoffman Status new => assigned
2009-09-11 17:30 Bill Hoffman Assigned To => David Cole
2010-06-23 14:51 Keith Gardner Note Added: 0021147
2010-09-09 17:41 David Cole Priority normal => high
2010-11-10 21:03 David Cole Relationship added related to 0006363
2010-11-10 21:09 David Cole Target Version => CMake 2.8.4
2011-01-10 09:40 David Cole Relationship added related to 0009148
2011-01-10 10:13 David Cole Note Added: 0024532
2011-01-10 14:46 David Cole Note Added: 0024547
2011-01-10 15:07 Keith Gardner Note Added: 0024553
2011-01-11 09:54 David Cole Note Added: 0024579
2011-01-11 09:54 David Cole Target Version CMake 2.8.4 =>
2011-01-11 11:00 Keith Gardner Note Added: 0024589
2011-10-26 00:02 David Cole Assigned To David Cole =>
2011-10-26 00:02 David Cole Status assigned => backlog
2015-09-24 16:11 Richard Shaw Note Added: 0039476
2016-06-10 14:27 Kitware Robot Note Added: 0041563
2016-06-10 14:27 Kitware Robot Status backlog => resolved
2016-06-10 14:27 Kitware Robot Resolution open => moved
2016-06-10 14:27 Kitware Robot Assigned To => Kitware Robot
2016-06-10 14:30 Kitware Robot Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team