KDE-buildsystem-basics package ?

[Alexander Neundorf]

On Saturday 21 January 2012, Stephen Kelly wrote:
> Alexander Neundorf wrote:
...
> >> Which I prefer to
> >> 
> >> bar_add_executable(foo TEST ...)
> >> 
> >> because it doesn't pollute the API for adding executables with something
> >> orthogonal (testing related stuff).
> >> 
> >> Setting the WIN32 and MACOS_BUNDLE parameters is also not needed in the
> >> add_executable call, but can also be done with PROPERTIES.
> > 
> > Oh, I didn't know that. That must be "new" ;-)
> :
> :)
> 
> Also keep in mind that any perceived limitations are patchable.

...until the 2.8.8 release I'd say.
 
> The documentation indicates that these things work as properties too, but I
> haven't tried them. Even if they don't work, we do have expertise to change
> CMake in sensible ways to remove any perceived roadblocks it has.
> 
> >> If we can add to CMake something like:
> >> 
> >> set(CMAKE_GUI_EXECUTABLES 1) # CMake sets the platform specific gui
> >> 
> >>                              # properties on executable targets
> > 
> > The obvious thing to do would be to initialize them also from cmake
> > variables, as other properties, i.e. from CMAKE_WIN32 and
> > CMAKE_MACOS_BUNDLE. Hmm, OTOH this sounds actually like two quite generic
> > variable names :-/
> > 
> > That must be discussed on the cmake-developers list.
> 
> Yes.

Can you do that please ?
 
> >> > INCLUDE_INSTALL_DIR must be set somewhere, and making it optional
> >> > whether it comes from some package or defining it in the project
> >> > itself will make for really ugly and long, i.e. hard to maintain,
> >> > CMakeLists.txt in all the framework libraries.
> >> 
> >> I think INCLUDE_INSTALL_DIR is not a great example. It's very odd for it
> >> to be anything other than 'include' right?
> > 
> > That's what I wondered too.
> > Does it actually make sense to support modifying all of the install dirs
> > ?
> 
> I don't know of any reason to be able to change the name of the 'include'
> directory or almost any other (with the exception of lib${LIB_PREFIX}).

Wrong, since debian multiarch :-P
From current GNUInstallDirs.cmake:

set(_LIBDIR_DEFAULT "lib")
# See http://wiki.debian.org/Multiarch
if(CMAKE_SYSTEM_NAME MATCHES "Linux" AND NOT CMAKE_CROSSCOMPILING)
  if (EXISTS "/etc/debian_version") # is this a debian system ?
    if(CMAKE_LIBRARY_ARCHITECTURE)
      set(_LIBDIR_DEFAULT "lib/${CMAKE_LIBRARY_ARCHITECTURE}")
    endif()
  else() # not debian, rely on CMAKE_SIZEOF_VOID_P:
    if(NOT DEFINED CMAKE_SIZEOF_VOID_P)
      message(AUTHOR_WARNING "Unable to determine... ")
    else()
      if("${CMAKE_SIZEOF_VOID_P}" EQUAL "8")
        set(_LIBDIR_DEFAULT "lib64")
      endif()
    endif()
  endif()
endif()


> > See my mail on the cmake-developers list from January 10th "RFC: standard
> > (and not so standard) install dirs".
> 
> Yes, I saw that. Brad also suggested that installing the KDE conventional
> dirs from CMake:
> 
> Brad King wrote:
> > Why not create a KDEInstallDirs.cmake that comes with CMake?  It wouldn't
> > actually contain any KDE-specific code, just a documented layout standard
> > that could be used by KDE project or outside projects that like the KDE
> > install layout.
> 
> So it's not a completely wild idea :).

I wouldn't want that, because this would mean that in the case we need a new 
variable, we have to wait for the next cmake release, and then force everybody 
to update his cmake.

> > OTOH, if we come to a satisfying solution for creating the Config.cmake
> > files, it doesn't hurt to have them configurable, see the "Making writing
> > Config.cmake files easier - updated example" thread on kde-buildsystem.
> > 
> > Also, with GUNInstallDirs.cmake in CMake, they are also all configurable
> > (because they are apparently all configurable with autotools), so it's
> > probably ok.
> 
> Maybe so. In autotools it could be a historical feature of dubious value
> that no one has the guts to remove though. I don't know.

Yes, maybe. Probably. In Randa the packagers actually agreed that there is no 
real need to change e.g. INCLUDE_INSTALL_DIR.
But, if there is LIB_INSTALL_DIR and DATA_INSTALL_DIR, it is good that there 
is also INCLUDE_INSTALL_DIR. So whatever you install, there is probably a 
variable defined which you should use.
Whether it has to be in the cache is yet another issue.
But if it doesn't hurt, why not.

...
> >> Aren't there other ways of executing the tests uninstalled without
> >> scripts? I can run Grantlee tests uninstalled, and I don't have any
> >> wrapper scripts.
> > 
> > Can you run them too if you set the option CMAKE_SKIP_RPATH to TRUE ?
> 
> Indeed they fail to run uninstalled if I set that variable in the cache.
> 
> ./templates/tests/testbuiltins_exec: symbol lookup error:
> ./templates/tests/testbuiltins_exec: undefined symbol:
> _ZNK8Grantlee8Variable11isLocalizedEv
> 
> > Under Windows it sets PATH, which can be worked around by generating
> > executables and libraries into the same directory.
> > 
> > But yes, this is something which I think (i.e. not "know") which is
> > barely used. OTOH I think e.g. debian packagers disable RPATH
> > completely. So maybe they use it all the time.
> 
> Or maybe they run the tests after installation. Hopefully Sune can
> enlighten us.

Well, we could add an option to disable the install RPATH, and at least print 
a warning or disable the tests if CMAKE_SKIP_RPATH has been set.
Or should CMAKE_SKIP_RPATH only disable the RPATH for the install tree ?
Sounds kind of reasonable, but this would probably only be possible if at all 
with a policy.
 
...
> > The only reason I see to alias it is for compatiblity.
> > With the modularization I would expect that we expect developers become
> > more aware of which KDE libraries they are actually using, and then we
> > can assume that they know where the macros come from.
> 
> Given the discussions around modularization since the idea of frameworks
> has been discussed, I'm not so sure. KDE (application) developers don't
> want to know where the stuff comes from, and being forced to know would be
> uneasy.

I know.
But if we move them to the modules, IMO they should get their correct names.

...
> > * setting policies, RPATH, other cmake switches may go into a file
> > KDEConventions.cmake or KDEDefaults.cmake
> 
> Maybe (the policies thing still doesn't seem right to me).

Yes, how to handle the policies the best way is tricky. See also CMP0011.
Let's keep handling the policies a separate issue.

> > * these files should be in the same location
> 
> Maybe. I think if it makes sense to put some in ECM (as general good ideas
> for Qt frameworks in general or KDE frameworks in particular), and some
> higher in the umbrella, then that should be considered.
> 
> The question of what goes where can only be answered fully by doing the
> work.
> 
> > * there may be a file which includes them all, on top of the frameworks
> > package, for convenience. This may be in a different location.
> 
> Ok. That might invalidate my comment above, but I'll leave it in the email
> anyway.
> 
> > Really, the clean way to distribute these files would be to have a
> > package dedicated to them. They have a common purpose and a common
> > community: serving as buildfiles for KDE software, developed by the KDE
> > community. From that POV they would even be _the_ point which turns a
> > Qt-based library into a KDE frameworks tier 1 library.
> 
> One of the goals from Randa was that tier1 stuff would be stuff that should
> in an ideal world be in Qt, but isn't for any number of valid reasons
> (barrier to entry, licensing etc) - ie, they should be closer to Qt than to
> KDE.

Well, if "should ideally be in Qt" is the definition, than qwt and qxt are 
qualify already right now ;-P

...
> > I'd suggest coming to an agreement for the stuff in
> > FindKDE4Internal.cmake and KDE4Defaults.cmake first, and where to put
> > what, and after that we can go through the macros.
> 
> Sounds good to me.

Ok.
TODO:
-e-c-m: create ecm/kde-modules/ - Alex
-e-c-m: add KDEInstallDirs.cmake - Alex
-e-c-m: add KDECompilerSettings.cmake - Alex
-e-c-m: add KDEDefaults.cmake - Alex
-CMake: initialize WIN32 and MACOSX_BUNDLE target from variables - Stephen
-CMake: modify CMAKE_SKIP_RPATH behaviour ? Stephen
-CMake: simplify creating Config.cmake files - Yuri, Alex
-CMake: handle imported targets in CMAKE_REQUIRED_LIBRARIES - Alex


But, before doing this, which prefix should we use for the stuff in e-c-m ?
"KDE", "KDE4", "KDE5" "KF", "KF5", "KF1", something else ?
FindKDE4.cmake uses "KDE4", FindKDE3.cmake uses "KDE3".
I am in favour of having a version number in it (to make clear for which 
version it is). But I guess KDE5 is not really an option.


Still not fully decided are the macros.


Also, do we keep the cmake required version handling as it is now ?
Right now the required version is defined in FindKDE4Internal.cmake. The idea 
was that if you are able to build kdelibs, you should be able to build all of 
KDE SC at least. And kdesupport must build anyway.
So if kdelibs requires cmake 2.6.4, no package in kdesupport is allowed to 
require a higher version, and nothing in KDE SC is allowed to require a higher 
version.
This makes a lot of sense for the scenario that the developer builds his 
complete KDE SC from scratch.
Is this still our main scenario ?
Or should we consider the case that somebody has KDE frameworks installed, and 
just builds something against it, the main target ?
Then this wouldn't have to be that strict.

Alex