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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
