MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0012359CMakeCMakepublic2011-07-25 10:582012-01-02 15:56
ReporterRuss Tayor 
Assigned ToDavid Cole 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionno change required 
PlatformIntelOSWindowsOS Version7
Product VersionCMake 2.8.5 
Target VersionFixed in Version 
Summary0012359: Windows 7 CMAKE_INSTALL_PREFIX does not work within Visual Studio due to permission problems
DescriptionWindows 7 requires programs that copy files into Program Files to not only be run by users with permission to write there, but also to be "Run as administrator." This breaks the INSTALL build when it is set to there.

I attach a workaround under Additional Information that changes the install dir on all WIN32 platforms; if we could find just Windows 7, that could be better.

Basically, the default needs to be set to somewhere the user can write. /usr/local seems as good a place as any to me.
Steps To ReproduceBuild INSTALL project on Windows 7.
Additional Information###
# On Windows 7, it does not work to install in the default location,
# which is the Program Files directory, because you have to not only have
# file permission to write there but also "run as administrator." This
# means that "make install" from a Visual Studio project fails. To get
# around that, we need to set CMAKE_INSTALL_PREFIX to something other
# than the default. However, it is a cache variable that has already been
# set. If we make a local variable, it uses this rather than the cache
# variable and never tells the poor user what happened (the GUI location
# looks standard but the files end up somewhere else). If we make it a
# non-forced cache variable, it already has a value so does not change.
# If we make it a forced cache variable, it gets overwritten everytime
# and the user cannot change it on the GUI. So we have a workaround here.
# We make a cache variable that records whether we have ever forced the
# install prefix. If not, we force it. If so, we don't force it again.
# This has the effect of setting it the first time cmake is run, showing
# the change in the GUI, and also letting the user change the value in
# the GUI if they don't like what we did. If I knew how to do this only
# happen on Windows 7, I'd make the if(WIN32) more specific.
if (WIN32)
        if (NOT ONCE_SET_CMAKE_INSTALL_PREFIX)
                set(ONCE_SET_CMAKE_INSTALL_PREFIX true CACHE BOOL
                        "Have we set the install prefix yet?" FORCE)
                set(CMAKE_INSTALL_PREFIX /usr/local CACHE PATH
                    "Install path prefix, prepended onto install directories"
                    FORCE)
        endif (NOT ONCE_SET_CMAKE_INSTALL_PREFIX)
endif (WIN32)
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2011-07-25 10:58Russ TayorNew Issue
2011-07-25 14:50David ColeAssigned To => David Cole
2011-07-25 14:50David ColeStatusnew => assigned
2011-07-25 14:56David ColeNote Added: 0027067
2011-07-25 14:56David ColeStatusassigned => resolved
2011-07-25 14:56David ColeResolutionopen => no change required
2011-07-25 15:48Russ TayorNote Added: 0027068
2011-07-25 15:48Russ TayorStatusresolved => feedback
2011-07-25 15:48Russ TayorResolutionno change required => reopened
2011-07-25 15:48Russ TayorNote Edited: 0027068bug_revision_view_page.php?bugnote_id=27068#r382
2011-07-25 16:06David ColeNote Added: 0027069
2011-07-26 13:29David ColeNote Added: 0027071
2011-07-26 13:29David ColeStatusfeedback => resolved
2011-07-26 13:29David ColeResolutionreopened => no change required
2012-01-02 15:56David ColeNote Added: 0028106
2012-01-02 15:56David ColeStatusresolved => closed

Notes
(0027067)
David Cole   
2011-07-25 14:56   
This is really the same as it has been for a while now. Same thing is true with Windows XP and Windows Vista: users don't have write privileges in Program Files unless they run as an admin.

You may easily change the value of CMAKE_INSTALL_PREFIX as you've done in your proposed "work-around" -- but we will not change the default value of CMAKE_INSTALL_PREFIX for this reason.

On many Unix installations, changes to /usr/local also requires admin privileges, so I would not recommend making that your default choice, if you are a fan of the default choice working for non-admin type folks.
(0027068)
Russ Tayor   
2011-07-25 15:48   
In XP and Vista you had to be an administrator to run there. On Windows 7, you have to be an admin, and IN ADDITION you have to have done a special "run as administrator" on the operation that does the writing. When you copy a file in Windows 7, a little shield shows up telling you that the OS will do this for you. In Visual Studio, you are out of luck. There is no shield-equivalent in Visual Studio. It just fails. So even if you are an admin, and are logged as such, you cannot build the INSTALL project.
(0027069)
David Cole   
2011-07-25 16:06   
As a Visual Studio user, I do not expect to be able to build the INSTALL project unless I have first set CMAKE_INSTALL_PREFIX to a location that I have write privileges to. I expect it to fail if I leave it at the default of "C:\Program Files".

If you do "run as administrator" on Visual Studio, then you should be able to build the INSTALL target, even on Windows 7 and even in Program Files. If not, then you have to change the value of CMAKE_INSTALL_PREFIX for it to work.

The value of CMAKE_INSTALL_PREFIX is meant to be adjusted by the developer building the software so he can install it where he wants to. The default value CMake provides is meant to be a reasonable place for installing machine-wide applications. "/usr/local" is not reasonable on Windows.

If you would like to provide a project-specific install prefix for your own project, then provide a project-specific CMake variable for it, and put your own reasonable default value into it, and then force the CMAKE_INSTALL_PREFIX to mirror it always, like this:

  set(CMAKE_INSTALL_PREFIX "${PROJECT_CMAKE_INSTALL_PREFIX}" CACHE INTERNAL "prefix override")

(INTERNAL always implies FORCE, and it also hides it from the cmake-gui so users don't think they can change it...)
(0027071)
David Cole   
2011-07-26 13:29   
Please see discussion in previous notes.
(0028106)
David Cole   
2012-01-02 15:56   
Closing resolved issues that have not been updated in more than 4 months.