KDE/kdelibs/cmake/modules

Dario Freddi drf54321 at gmail.com
Sun Sep 6 12:36:02 CEST 2009


Here it goes, new diff for findkde4internals and kde4macros (and the full 
polkitqt file :D) some comments below

In data sabato 05 settembre 2009 21:53:36, Alexander Neundorf ha scritto:
[snip]
> Yes, please.
> This would add another macro which creates an executable, but without
> providing real benefit. I mean, every KDE developer should know
> 
> kde4_add_executable()
> target_link_libraries()
> install(TARGETS)
> 
> So there's nothing new here.
> Now to help with getting that stuff installed correctly we can provide a
>  macro which helps with that. Which means there is 1 new thing to learn but
>  the other code stays understandable for everybody else who don't know
>  about KAuth.

Done, but with a modification. The function (ah, tested and function works 
nice, btw) also accepts the helper target and installs it. This for a variety 
of reasons:

1. The macro has to know the target name since one of the configured files 
needs it
2. The helper has to be installed in libexec_install_dir, so we also make sure 
that it gets installed into the correct location.

The cmake code client-side would then be:

kde4_add_executable(kcmremotewidgetshelper private/remotewidgetshelper.cpp)
target_link_libraries(kcmremotewidgetshelper kdecore)

kde4_install_auth_helper_files(kcmremotewidgetshelper 
org.kde.kcontrol.kcmremotewidgets root)

kde4_auth_install_actions(org.kde.kcontrol.kcmremotewidgets 
kcm_remotewidgets.actions)

I hope this makes up as a good compromise

> 
> Adding KDE4_ADD_AUTH_HELPER_EXECUTABLE() would also be 1 new thing to learn
> and it doesn't show that it will also install and link to kdecore. So the
> name would have to be something like
> KDE4_ADD_AUTH_HELPER_EXECUTABLE_LINK_TO_KDECORE_AND_INSTALL()
> I guess we don't want that ;-)

Hehe, right :D

> 
> > > Macro KDE4_AUTH_REGISTER_ACTIONS:
> > >
> > > Maybe an "install" in the name of the macro would be a good idea, since
> > > it installs stuff.
> >
> > Uhm, you are right. KDE4_AUTH_INSTALL_ACTIONS? But it seems confusing to
> > me. REGISTER_AND_INSTALL is making it too long IMHO. Any other
> > suggestions?
> 
> I don't have a problem with long names.
> 
> Or just KDE4_INSTALL_AUTH_ACTIONS() ?

Done this way :)

> Do I understand correctly that the registering is part of a correct
> installation of this stuff ? Then one could argue that the register part is
> included in the install part. And the docs will say it anyway :-)
> (having "install" in the name 1) makes it more obvious and 2) helps when
> grepping for "install" in the source tree).
> 
> Alex
> 

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

Dario Freddi
KDE Developer
GPG Key Signature: 511A9A3B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FindPolkitQt.cmake
Type: text/x-cmake
Size: 3690 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20090906/11f291d0/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cmake_done_right_revenge.diff
Type: text/x-patch
Size: 7517 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20090906/11f291d0/attachment.diff 
-------------- 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/20090906/11f291d0/attachment.sig 


More information about the Kde-buildsystem mailing list