[PATCH] bug 174806

[Alexander Neundorf]

Hi Michael,

I guess you have seen my comments from yesterday ?
http://lists.kde.org/?l=kde-buildsystem&m=123713315912581&w=2

On Monday 16 March 2009, Michael Witten wrote:
> As a solution to the following bug:
>
>     http://bugs.kde.org/show_bug.cgi?id=174806
>
> I have 2 patches. One for kdelibs (it involves some
> cleanup/streamlining for the affected code):
>
>     http://bugsfiles.kde.org/attachment.cgi?id=32117
>
> and one for kdebase:
>
>     http://bugs.kde.org/attachment.cgi?id=32118
>
> The patches apply to revision 939041 (trunk).
>
> Here is the comment:
>
> I've got *2* patch[es] that [try] to make this whole enterprise as
> transparent as possible.
>
> The crux of the problem is that KDE developers like to configure
> CMAKE_INSTALL_PREFIX so that it points to some directory under
> ${HOME}, while python has traditinally dictated that modules be
> installed to a system-wide site-packages directory. This causes a
> clash of permissions: `make install' can't install to this system-wide
> site-packages directory without special priveleges (for instance,
> `sudo make install').

Yes. 
But please see the python support files in kdelibs as something independent 
from KDE, i.e. they should be usable also outside of KDE, like being ported 
back to the official cmake.

Testing whether CMAKE_INSTALL_PREFIX is under $HOME will work for many cases, 
but not for all (I e.g. have my /opt writable by me from my user account, so 
your patch wouldn't work in my (probably rare) case).

What about something like this:
currently you check at cmake time where CMAKE_INSTALL_PREFIX points to.
Instead of just checking the directory, how about trying to write a tiny file 
there and remove it again ?
If it works, use the user-site packages (because we assume that cmake runs 
with user privileges, and if he can write to CMAKE_INSTALL_PREFIX, it is 
maybe not a system-wide installation), otherwise if he can't write, use the 
system-wide directory (because we assume the install will be done with root 
privileges).
Hmm, still a lot of guessing and it can go wrong.

How about just providing a cmake OPTION() to switch between the two 
directories ?
This way there would be at least a user-accessible way to make it work and no 
guessing from the cmake-side would be involved.

Or how about this, only a slightly modified version of the logic in your 
patch: 

# if the user used ccmake or cmake-gui or -D, it will be already
# in the cache
if (NOT PYTHON_SITE_PACKAGES_INSTALL_DIR)

   # use this just as a hint
   if (CMAKE_INSTALL_PREFIX inside $HOME)
      set(DEFAULT_INSTALL_TO_USER_SITE_PACKAGES TRUE)
   else
      set(DEFAULT_INSTALL_TO_USER_SITE_PACKAGES FALSE)
   endif

   # now the option which decides where the python stuff will go
   option(PYTHON_INSTALL_TO_USER_SITE_PACKAGES "If enabled,..."
          ${DEFAULT_INSTALL_TO_USER_SITE_PACKAGES } )

   # and the "multiplexer"
   if (PYTHON_INSTALL_TO_USER_SITE_PACKAGES )
      set(PYTHON_SITE_PACKAGES_INSTALL_DIR ${PYTHON_USER_SITE_PACKAGES_DIR})
   else
      set(PYTHON_SITE_PACKAGES_INSTALL_DIR ${PYTHON_SITE_PACKAGES_DIR})
   endif

endif


> P.S.
> The use of $ENV{HOME} may not work for Windows. Input?

Not sure, I wouldn't be surprised if it returned C:\Documents and 
Settings\<username>\ or how that path is exactly. In doubt, wait until 
somebody complains ;-)

Alex