On Sun, Mar 11, 2012 at 12:18 AM, Alexander Neundorf <neund...@kde.org> wrote: > On Saturday 10 March 2012, David Faure wrote: >> On Monday 27 February 2012 17:48:44 Alexander Neundorf wrote: >> > A common setup will be that "core" developers are building all frameworks >> > libraries. >> > Let's say some tier1 library, e.g. kcore needs Qt 5.1.2 and cmake 2.8.9. >> > Another tier1 library, let's say solid, maybe says it needs Qt 5.1.0 and >> > cmake 2.8.8. >> > >> > But since due to kcore already Qt 5.1.2 and cmake 2.8.9 are installed and >> > available, it may, no, it will happen that solid accidentially uses >> > features from Qt 5.1.2 and/or cmake 2.8.9. The developer will not even >> > notice that the required versions of Qt and cmake (5.1.0 and 2.8.8) are >> > wrong. >> > So other developers will try to build solid and it will fail at >> > buildtime. >> >> Accidentally using "too new" features (from cmake, Qt, or any other >> dependency) already happens frequently with different KDE modules. Or even >> within the same module, one developer uses a "too new" feature, which >> breaks compilation for other developers on the same module. >> So this is not an argument for this discussion, it's unrelated and mostly >> unavoidable. > > Continuous/nightly builds using the official minimum required versions would > help.
We have Continuous builds of some projects already - see http://build.kde.org/ > >> > Do we really want that any of the let's say 20 libraries can require a >> > newer version Qt and so enforce a rebuild for everybody ? or cmake ? >> >> This, on the other hand, refers to *documented* (not accidental) >> differences in requirements. Note that we already have exactly this in KDE >> too. When I ported konversation to new-in-kdelibs-4.5 API (at a time where >> 4.6 was already out), it broke compilation for people compiling >> konversation on top of kdelibs-4.4, which was apparently still a supported >> target for konversation. It makes things difficult for people like me (who >> like to touch everything in KDE), but on the whole it's not so crazy that >> different modules have different requirements on their dependencies. > > To summarize: do you say it is ok to let every KDE frameworks git repository > decide for its own which versions of Qt and CMake it requires ? > > For me, this would be the least work (implementation wise): we'll have a fully > independent set of libraries with maintainers, who all take care that > everything is working fine, and using those independent libraries together > makes sense. > > This gets us AFAICT to the same dependency situation as gnome has. > > Also, this means the term "KDE frameworks" doesn't actually mean a lot. > I mean, what would make a library a "KDE frameworks library" ? > Being part of the KDE SC releases ? > > But I'm really not sure this will result in a pleasant experience for > developers and maybe also packagers to build the whole thing. > > If we go that route, I'd like to have somebody volunteering to do the support > for all those people who will have problems building due to dependency > problems, or a strange mixture of versions that has been found, or people > complaining that they already have to upgrade their cmake again because some > library upped their required version. I don't feel like doing the support for > this. > > If we want to keep a mostly smooth experience for developers working on > multiple parts/the whole KDE SC (which is IMO one of the things which make up > "KDE"), this is IMO not the way to go. > > Alex > _______________________________________________ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Regards, Ben _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
