Review Request: Don't lose the original CMAKE_MODULE_PATH

[David Faure]

> 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.

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).


- 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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20120805/e58acdff/attachment.html>