> On Aug. 5, 2012, 9:12 a.m., David Faure wrote: > > tier2/kconfig/CMakeLists.txt, line 7 > > <http://git.reviewboard.kde.org/r/105863/diff/1/?file=76038#file76038line7> > > > > Ah, damn, there are conflicting goals here. > > > > We removed ${CMAKE_MODULE_PATH} on purpose so that each framework (in > > this case, tier2/kconfig) builds standalone, i.e. doesn't use any cmake > > file from the rest of kdelibs. As long as we have independent frameworks > > being built together in one big kdelibs (which is a temporary situation), > > this is a way to ensure that each module is self-contained in terms of > > cmake files. > > > > Now let's talk about FindKDEWin.cmake: can't we get rid of that? Try to > > think of kconfig as "a pure Qt-based library", like say, soprano, qca, or > > qjson. These libs don't use and don't need FindKDEWin.cmake, right? So why > > would kconfig need that additional layer? I know it was a necessary layer > > to get KDE4 code to compile on Windows, but the goal with KF5 is to remove > > layers and ensure that Qt and cmake have everything we need to compile our > > standalone libs on top of them. > > > > Please evaluate what needs the "kdewin" (library, right?), and whether > > that code can't be ported to "pure Qt" instead. > > Patrick Spendrin wrote: > Yes, when I started with kf5 I already tried to put the easy parts into > frameworks itself. Some stuff will be really hard, especially where > "excessive" use of posix functions is used. Iirc kconfig was one of these, so > it might be needed/wanted to keep the dependency for that part. One issue I > wanted to address is that kdewin should ship a cmake Config.cmake so that we > at least do not need the FindKDEWin.cmake anymore. > > The question for KDE actually is how much code from kdewin can/should go > into those libraries before it is better to keep kdewin. > > David Faure wrote: > I said "port to pure qt", not "duplicate kdewin code everywhere" :-) > > I think the right approach is really: "hmm, wait, shouldn't Qt offer a > way to do this, cross-platform"? If it does, port to that. If it doesn't, add > it to Qt5 and submit it to gerrit. (Then we can look into what this means for > the Qt4-based build: ifdef'ing out the code, i.e. breaking behavior with qt4, > is a valid option). > > But to discuss this further we need actual details of the "excessive use > of posix functions" in kconfig. > > A quick grep made me find only one, in KConfigIniBackend::isWritable() : > if (::access(QFile::encodeName(filePath).constData(), W_OK) == 0) > { > I added some time ago a comment that says > // Qt 5 TODO: QFileInfo::canBeCreated or something. > But actually we can implement this one already on top of Qt, using > QFileInfo::isWritable() on the parent directory. > (There's an issue if the parent dir doesn't exist yet, but that issue was > there already in the ::access() call, AFAICS). > > Alexander Neundorf wrote: > I agree with David. > A possible alternative would be to put FindKDEWIN.cmake into e-c-m, and > then use it from there. > > > Patrick Spendrin wrote: > I added a KDEWinConfig.cmake as a first step so that the FindKDEWin.cmake > is not needed anymore. > I just looked into my local patches, and the question about having kdewin > happens again in karchive, of course also in kdecore, kjs, kde4support and > likely some others. > > Kevin Ottens wrote: > Is this discussion still relevant? If not this entry should probably be > closed. > > Alexander Neundorf wrote: > Whether a FindKDEWin.cmake is used or whether kdewin installs a > KDEWinConfig.cmake file does not change the fact that this means that these > tier1-libs have a dependency additionally to Qt (... doesn't that make them > tier2 ?). > > > Kevin Ottens wrote: > Yes it does. I in fact raises the question of the validity of that > approach... We're basically trying to recreate UNIX syscalls on top of > Windows where it's behavior differ. I doubt we need to have that much of low > level code and should encourage using higher level constructs instead > (probably from the lower parts of Qt itself). > > I'd be interested in a list of the places where kdewin is used and why. I > think most of those calls are just very old code not ported to more modern > APIs. We should get rid of those instead of nurturing a kdewin IMO.
Please discard this review request and help with porting KF5 away from unix syscalls instead :) We made much progress in that direction, I believe, someone should try again on windows to see where it first breaks. - David ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105863/#review16879 ----------------------------------------------------------- On Aug. 4, 2012, 9:11 p.m., Andrius da Costa Ribas wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/105863/ > ----------------------------------------------------------- > > (Updated Aug. 4, 2012, 9:11 p.m.) > > > Review request for KDE Frameworks and Patrick Spendrin. > > > Description > ------- > > Keep the paths already in CMAKE_MODULE_PATH when adding ECM_MODULE_PATH and > other search-paths into it. > > > Diffs > ----- > > CMakeLists.txt f20069c > tier2/kconfig/CMakeLists.txt c4b2cf6 > > Diff: http://git.reviewboard.kde.org/r/105863/diff/ > > > Testing > ------- > > Before this adjustment it was not possible to proceed with the build due to > missing Find*.cmake (e.g.: FindKDEWin.cmake) files. > > > Thanks, > > Andrius da Costa Ribas > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
