Review Request: Don't lose the original CMAKE_MODULE_PATH

[Alexander Neundorf]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20120806/0ba732c1/attachment.html>