KDE-buildsystem-basics package ?

[Alexander Neundorf]

On Sunday 22 January 2012, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > 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.
> 
> Why the hard requirement already? 

If the first release of the frameworks is in June, then 2.8.8 will be the most 
recent cmake release.

> If something we need or makes so much sense that we should use it,

This actually did not happen too often in the last 5 years, see below. If we 
know there is something we want to have in cmake, we should try to get it in.

...
> > I know.
> > But if we move them to the modules, IMO they should get their correct
> > names.
> 
> If they move to modules I agree that they should get names consistent with
> the modules that they are in.
> 
> You seem to be saying that you think that applications should use those
> same names and not use aliases.


Yes.
Except if they are using a kdelibs4 compat module.
 
...
> > But, before doing this, which prefix should we use for the stuff in e-c-m
> > ? "KDE", "KDE4", "KDE5" "KF", "KF5", "KF1", something else ?
> 
> KF5.

It seems I'm the only who one thinks this will be the first release of the KDE 
frameworks and not the fifth...

...
> > 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.
> 
> I'm not sure. I'm not a fan of requiring that the CMake version we use must
> be several years/releases old. I also don't think we should depend on a new
> version of CMake each time it is released though. If we need features in a
> newer version, lets move to that newer version in a reasonable timeframe.

My policy is to increase the required cmake version whenever something is 
added to cmake that we _really_ need.
And in this case, wait until it is available as a package for the major 
distributions:

June 2006: cmake 2.4.3
March 2007: cmake 2.4.5 (released December 2006)
July 2008: cmake 2.6.0  (released May 2008)
April 2010: cmake 2.6.4 (released May 2009)

Now since cmake 2.8.3 there are several things in cmake we should make use of. 
But I don't want to require 2.8.3 for kdelibs 4 now, and upgrade this to 2.8.8 
in 3 months already again.

So, yes, I'd actually like to upgrade the required cmake version for stable 
kdelibs, I'm just not sure whether this is actually allowed. Freeze and all.

Once the first frameworks release (not preview or anything) is out, I'd like 
to stay with the policy not to upgrade cmake too often. Once a year should be 
fine, and only if it is really useful, not for minor conveniences.

Alex