KDE/kdelibs/cmake/modules

[Dario Freddi]

P.S.: Whenever I will commit this one, I will increase KDELibs version number, 
make the needed modifications to kdebase-workspace and set its dependency from 
kdelibs on the new version number. Please tell me if that's ok as well

In data giovedì 03 settembre 2009 20:50:28, Alexander Neundorf ha scritto:
: > On Thursday 03 September 2009, Dario Freddi wrote:
> > In data giovedì 03 settembre 2009 20:02:38, Alexander Neundorf ha scritto:
> > > Now that it is part of kdecore the searching for the installed files is
> > > not really necessary anymore.
> > > kauth/dbus_service.stub and kauth/dbus_policy.stub will be installed to
> > > ${DATA_INSTALL_DIR}, which is ${KDE4_DATA_INSTALL_DIR}  for everybody
> > >  outside kdelibs.
> >
> > Which brings me to a problem. Some stuff in KDELibs actually need those
> > variables. For the time being, I worked around that this way:
> >
> > include(MacroKAuth)
> >
> > set( KDE4_KAUTH_DBUS_POLICY_STUB
> > ${CMAKE_SOURCE_DIR}/kdecore/auth/backends/dbus/dbus_policy.stub)
> > set( KDE4_KAUTH_DBUS_SERVICE_STUB
> > ${CMAKE_SOURCE_DIR}/kdecore/auth/backends/dbus/dbus_service.stub)
> > set( KDE4_KAUTH_POLICY_GEN kauth-policy-gen)
> >
> > But it's damned ugly. Also, consider that these three variables will just
> > be used internally in KAuth macros. Given that, what is the ultimate
> > right way?
> 
> Inside the macros you could check for _kdeBootStrapping (set in
> FindKDE4Internal.cmake if kdelibs itself is being built), or for
> kdelibs_SOURCE_DIR (is set if this CMakeLists.txt is somewhere below a
> project(kdelibs) call) and then adapt the directory accordingly.
> 
> > > So you can basically just use
> > >  ${KDE4_DATA_INSTALL_DIR}/kauth/dbus_service.stub and
> > >  ${KDE4_DATA_INSTALL_DIR}/kauth/dbus_policy.stub directly in the macros
> > > (we also don't check for the existence of every single installed other
> > > file of kdelibs, like e.g. every single header).
> > > If you really want to be sure, you can use
> > > find_file(_kauth_really_exists
> > >           NAMES kauth/dbus_policy.stub
> > >           PATHS ${KDE4_DATA_INSTALL_DIR}
> > >           NO_DEFAULT_PATH)
> > > or
> > > if(EXISTS ${KDE4_DATA_INSTALL_DIR}/kauth/dbus_policy.stub)
> > > to check whether the file really does exist (but it shouldn't be
> > >  necessary). The proper way to check that would be to increase the
> > > kdelibs version number and require the appropriate version in the KDE
> > > modules needing kauth.
> >
> > Well, KAuth will be in from 4.4, so I guess that's doable
> 
> I mean, right now the version number of kdelibs could be increased.
> 
> > > The executable kauth-policy-gen should be handled like e.g. meinproc4.
> > > This means when installing it, it should be added to
> > > the "export-set" "kdelibsToolsTargets", which is a set of targets which
> > > are "exported" into a special cmake file which is installed when
> > > installing kdelibs (see bottom of kdelibs/CMakeLists.txt). Then later
> > > on in FindKDE4Internal.cmake the LOCATION property of the then imported
> > > target should be used to set KDE4_KDE4_KAUTH_POLICY_GEN (which should
> > > be renamed to KDE4_KAUTH_POLICY_GEN_EXECUTABLE).
> >
> > Ok, I will do that
> >
> > > The file MacroKAuth.cmake can then be removed. To give people a hint
> > > why their build suddenly breaks if the still have include(MacroKAuth)
> > > somewhere, you can replace the contents of MacroKAuth.cmake for some
> > > time with just:
> > >
> > > message(FATAL_ERROR "Don't include(MacroKAuth) anymore, it's now
> > > included in find_package(KDE4)")
> >
> > Nice, will do as well :)
> >
> > /me is really happy to learn this stuff for cmake, thanks Alexander :)
> >
> > P.S.: I would paste this mail, a bit refactored, on Techbase. Can be
> > damned useful
> 
> Would or will ?
> Which part exactly ?
> The stuff about exporting/importing should be in the "cmake news with 4.2"
> page on techbase.
> 
> Alex
> 

-- 
-------------------

Dario Freddi
KDE Developer
GPG Key Signature: 511A9A3B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20090905/fbebeca5/attachment-0001.sig