please make it easier to hack on frameworks

[Aaron J. Seigo]

On Tuesday, April 30, 2013 11:20:47 Stephen Kelly wrote:
> I am clueless to understand why building cmake from git and installing it
> into your kf5 prefix is a showstopper. Can you tell me?

Time is limited. 

Every repository that I have to build (e.g. cmake) that is not the repository I am trying to work on 
(e.g. plasma-frameworks) is time lost getting my tasks done.

Moreover, it is one more thing to learn: where is cmake's git, how to build it, etc. For me that is not 
a big issue (I've build cmake from source many times in the past) but for people who might want 
to work on frameworks this kind of thing becomes a show stopper. Eventually they run into so 
many things they have to locate, build and keep up to date that they have no time / energy / 
desire to keep on.

If we want to ensure that it is as difficult as possible to contribute to frameworks, congratulations, 
we're doing a great job of that. If frameworks is meant to be a project for you, Kevin, David and 
Alexander to work on then by all means don't worry about this. If the idea is, however, to make it 
attractive to others to work on, then some things need to change.

The idea that it is ok to rely on unreleased software as part of the toolchain is one of those things.

> The fact that the required cmake version is a dated snapshot is an
> implementation detail. 

It is not an "implementation detail" if it impacts every single person who feels the itch to work on 
frameworks.

Given that plasma-framework depends on a relatively recent version of frameworks, this 
"implementation detail" is now screwing with barrier to entry to plasma-framework.

If the idea is to have users of frameworks, then frameworks needs to stop being a liability in terms 
of increasing the barrier to entry.

> http://build.kde.org/job/cmake/. I assumed anyone who cares would be
> building cmake from git because it's the most convenient and smart way to do
> it.

You assumed wrongly. I'm also not sure how "build from git" is more convenient than "zypper up".

> This use of the CMake RC in frameworks has found actual bugs in the cmake
> release candidates (most recently in the 2.8.11 RC 1), so we should continue
> to depend on the latest release candidate. CMake release candidates are
> actual candidates for release, that's not just a label.

So kdelibs frameworks is a test environment for cmake? I can understand that from the cmake 
perspective, but it is not ammenable from the perspective of kdelibs development. tail.wag(dog)

-- 
Aaron Seigo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20130430/616bdbed/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20130430/616bdbed/attachment.sig>