On Monday 06 August 2012, Patrick Spendrin wrote: > > 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#file76038li > > > ne7> > > > > > > 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. > > I added a KDEWinConfig.cmake as a first step
Can you post a link to it here ? Thanks Alex
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel