KDE-buildsystem-basics package ?

[Stephen Kelly]

Alexander Neundorf wrote:

> 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.

Then I think Kevins message is already causing confusion :)

I don't think the first release is to be in June. Kevin is talking about a 
technical preview milestone which is not a freeze of any sort, but is 
designed to motivate people who get motivated by having deadlines. It's 
nothing 'harder' than that afaik, but needs to be 'released' for practical 
reasons of being a special milestone.

It shouldn't have any effect on our dependencies. It's not a dependency 
freeze. It might make sense for other reasons to depend on CMake 2.8.8, but 
this technical preview thingy shouldn't be that reason.

> 
>> 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.

Yes.

> 
> ...
>> > 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.

I don't mind whether the aliases are in a kdelibs4 compat module or in an 
umbrella 'fully maintained and you should use it' module. 

The way I see it, the 'umbrella' thing that we talk about is 'kdelibs5', 
which is significantly smaller than kdelibs4, and which depends on KDE 
frameworks in the same way that kdelibs4 depends on kdesupport. Then KDE 5 
applications depend on kdelibs5 and very little changes for them.

The aliases would be cheap and may have to exist anyway somewhere even if in 
a compat module. Put the question to application developers and see what 
they say.

>  
> ...
>> > 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...

It's just a name and a number. It's not really worth discussing IMO. 

If we go with KF5 now and then someone decides that it really really must be 
KF1 instead, then we change the macros with a sed script. No big deal :).

> ...
>> > 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:

Do other packages in distros have higher (sooner) CMake requirements than 
KDE has? If higher version requirements are already imposed by other non-KDE 
packages(I have no idea), then it's not really valuable for us to stick with 
2.5 year old versions of it. We use cutting edge Qt most of the time too. I 
don't see why our CMake required version strategy must be so different. Qt 
and CMake are our two most important dependencies.

I also don't mean that we should depend on new CMake as soon as it's 
released of course. A 1 year old dependency is fine I'm sure.

Has it been a maintenance burden to make sure no one uses features added 
after 2.6.4? Have you tried to build all of KDE with 2.6.4 to verify that it 
actually works? If it doesn't, that would be interesting information to know 
whether it makes sense to depend on something 2.5 years old and whether we 
are successful in maintaining that. Could you try that?

I'd say it makes more sense to depend on whatever the latest 
ubuntu/suse/fedora comes with (many KDE developers use that anyway for their 
Qt dependency needs I'm sure).

That said, I'll defer to you on the CMake version requirement, but I just 
don't understand using a 2.5 year old release :).

> 
> 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.

I'm also not sure what the value would be in such a version bump now. It's 
not a frameworks-relevant discussion anyway, but something for the 
buildsystem list.

> 
> 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.

Fair enough.

Steve.