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

It may or may not be possible without patching NSIS.

http://sourceforge.net/tracker/?func=detail&atid=373085&aid=2355677&group_id=22049 [^]

(0017209)
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.

(0017210)
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.

if(CMAKE_SIZEOF_VOID_P EQUAL 8)
set(CPACK_NSIS_PROGRAMFILES PROGRAMFILES64)
else()
set(CPACK_NSIS_PROGRAMFILES PROGRAMFILES)
endif()

Then change the following two lines in NSIS.template.in
- InstallDir "$PROGRAMFILES\@CPACK_PACKAGE_INSTALL_DIRECTORY@"
+ InstallDir "$@CPACK_NSIS_PROGRAMFILES@\@CPACK_PACKAGE_INSTALL_DIRECTORY@"

- StrCpy $INSTDIR "$PROGRAMFILES\@CPACK_PACKAGE_INSTALL_DIRECTORY@"
+ StrCpy $INSTDIR "$@CPACK_NSIS_PROGRAMFILES@\@CPACK_PACKAGE_INSTALL_DIRECTORY@"

Note that for my installer, only the second changed line seemed to make any difference.

(0017227)
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 NSIS.template.in file instead of adding a configured variable to fix part of it. Maybe use the already defined CPACK_SYSTEM_NAME variable.

(0017229)
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.

(0017230)
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.

(0021147)
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.

(0024532)
David Cole (manager)
2011-01-10 10:13

After the fix for the related bug, 0009148, you can now:
set(CPACK_NSIS_INSTALL_ROOT "$PROGRAMFILES64")

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.

(0024547)
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...)

(0024553)
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.

(0024579)
David Cole (manager)
2011-01-11 09:54

Keith:
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:
cpack_set_if_not_set(CPACK_PACKAGE_INSTALL_REGISTRY_KEY
"${CPACK_PACKAGE_NAME} ${CPACK_PACKAGE_VERSION}")

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.

(0024589)
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.

(0039476)
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.

(0041563)
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

Notes
(0017202) James Bigler (developer) 2009-08-24 19:14	It may or may not be possible without patching NSIS. http://sourceforge.net/tracker/?func=detail&atid=373085&aid=2355677&group_id=22049 [^]

(0017209) 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.

(0017210) 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. if(CMAKE_SIZEOF_VOID_P EQUAL 8) set(CPACK_NSIS_PROGRAMFILES PROGRAMFILES64) else() set(CPACK_NSIS_PROGRAMFILES PROGRAMFILES) endif() Then change the following two lines in NSIS.template.in - InstallDir "$PROGRAMFILES\@CPACK_PACKAGE_INSTALL_DIRECTORY@" + InstallDir "$@CPACK_NSIS_PROGRAMFILES@\@CPACK_PACKAGE_INSTALL_DIRECTORY@" - StrCpy $INSTDIR "$PROGRAMFILES\@CPACK_PACKAGE_INSTALL_DIRECTORY@" + StrCpy $INSTDIR "$@CPACK_NSIS_PROGRAMFILES@\@CPACK_PACKAGE_INSTALL_DIRECTORY@" Note that for my installer, only the second changed line seemed to make any difference.

(0017227) 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 NSIS.template.in file instead of adding a configured variable to fix part of it. Maybe use the already defined CPACK_SYSTEM_NAME variable.

(0017229) 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.

(0017230) 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.

(0021147) 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.

(0024532) David Cole (manager) 2011-01-10 10:13	After the fix for the related bug, 0009148, you can now: set(CPACK_NSIS_INSTALL_ROOT "$PROGRAMFILES64") 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.

(0024547) 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...)

(0024553) 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.

(0024579) David Cole (manager) 2011-01-11 09:54	Keith: 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: cpack_set_if_not_set(CPACK_PACKAGE_INSTALL_REGISTRY_KEY "${CPACK_PACKAGE_NAME} ${CPACK_PACKAGE_VERSION}") 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.

(0024589) 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.

(0039476) 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.

(0041563) 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.