Review Request 105863: 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.
> 
> 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
> 
>

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