On Tuesday 12 January 2010, Dario Freddi wrote: > Hello back, > > 2010/1/11 Alexander Neundorf <[email protected]> > > > On Sunday 10 January 2010, Dario Freddi wrote: > > > Sorry for the late answer, troubled life is back. > > > > > > On Wednesday 30 December 2009 21:38:12 Alexander Neundorf wrote: > > > [..] > > > > > > > In general determining install locations are the responsibility of > > > > the project which is being built. I mean, if I chose to install > > > > something to $HOME/inst it shouldn't matter where PolkitQt is > > > > installed. > > > > > > > > What we do for the other install dirs like BIN_INSTALL_DIR etc. in > > > > kdelibs is the following: > > > > if the variable (e.g. KDE4_AUTH_POLICY_FILES_INSTALL_DIR) has not > > > > been explicitely set, and if the current CMAKE_INSTALL_PREFIX is the > > > > same as the kdelibs install prefix, then we reuse the variable (e.g. > > > > KDE4_AUTH_POLICY_FILES_INSTALL_DIR) from kdelibs. > > > > > > > > Look for the macro _SET_FANCY() in > > > > kdelibs/cmake/modules/FindKDE4Internal.cmake. > > > > > > > > Does this do what you want ? > > > > > > Unfortunately not. The problem here is that we really want to store > > > some data: KAuth is backend based, and we have no knowledge at build > > > time (outside KDELibs) of which backend was built, hence how to handle > > > it. > > > > > > This is probably a reason why I'd put stuff in > > > CreateKDELibsDependencies.cmake. I'd add two variables: one, > > > KDE4_AUTH_BACKEND_NAME, carrying the name of the chosen backend, and > > > one, KDE4_AUTH_POLICY_FILES_INSTALL_DIR carrying the location of the > > > policy files install dir, if any (which is required unless we decide to > > > install findpolkitqt*.cmake). > > > > > > Now, the logic for selecting the backend name is > > > kdecore/auth/ConfigureChecks.cmake, where the KAUTH_BACKEND variable is > > > set. Once that is done, finding out the value of > > > KDE4_AUTH_POLICY_FILES_INSTALL_DIR is a breeze. The only problem I see > > > is that putting straight into > > > CreateKDELibsDependenciesFile.cmake set(KDE4_AUTH_BACKEND_NAME > > > ${KAUTH_BACKEND}) fairly doesn't work. > > > > I guess KAUTH_BACKEND is empty for you ? > > There are I think three way you can get values from child directories up > > their parent directories: > > > > 1) put them in the cache. > > This is "almost" done for KAUTH_BACKEND. > > There is the following code in kdecore/auth/ConfigureChecks.cmake: > > > > set(KAUTH_BACKEND "" CACHE STRING "Specifies the KAuth ...") > > ... > > if (POLKITQT_FOUND) > > set (KAUTH_BACKEND "PolkitQt") > > ... > > > > > > The first line puts KAUTH_BACKEND in the cache if it's not already there. > > So you can access this value ("") from the toplevel. > > Then, later on, there are several set(KAUTH_BACKEND ...) calls without > > the "CACHE" argument. This means they set the non-cache variable > > KAUTH_BACKEND, which hides the one from the cache, but which doesn't > > write the new value into the cache. > > To actually get this value into the cache, you need to use the FORCE > > argument for set: > > set( ... CACHE ... FORCE) > > This will write the value into the cache no matter what's already there > > in the cache. > > I guess this is what you want to do. > > It is. The attached patch does exactly this, and it works. It feels to > me a bit weirdo, though, that I have to set the docstring each and > every time. Maybe I am missing something?
No, not really. But putting the doc string into a variable and using this would probably be a very good idea. > Also, I changed the name of KAUTH_BACKEND into KDE4_AUTH_BACKEND_NAME > for consistency. I'll write somewhere about the change as well. > > > [snip] > > > > And I still think the install dir should be handled the same way the > > other install dirs are handled, i.e. it should take the same value as > > kdelibs if it is installed to the same prefix, it should be settable via > > the cache, and I wouldn't mind if it defaults to some other location if > > the > > CMAKE_INSTALL_PREFIX is different from the kdelibs location. > > It actually should be already so: as you can see from the patch, the > locations are based upon CMAKE_INSTALL_PREFIX (even if this might lead > to utter fails, which are however decently reported at build time), > and added to the cache. I'll have a closer look at this tomorrow. Alex _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
