> On Feb. 26, 2014, 4:36 p.m., Aurélien Gâteau wrote: > > My memory may be failing me, but I think it was actually decided to go the > > other way around for Qt5 includes: not prepending the module dir. Can > > anyone else confirm? This should be mentioned in the framework policies, I > > think. > > Alex Merry wrote: > Yeah, the conclusion was that using module names in includes caused more > trouble than it was worth. > > We're generally assuming that downstreams will use either qmake or CMake; > this shouldn't be an issue with either. > > Alex Merry wrote: > Although: see > http://mail.kde.org/pipermail/kde-frameworks-devel/2014-February/012052.html
Fun :/ I'd say we definitely need an official policy on this. - Aurélien ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116079/#review50945 ----------------------------------------------------------- On Feb. 26, 2014, 12:19 p.m., Michael Palimaka wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/116079/ > ----------------------------------------------------------- > > (Updated Feb. 26, 2014, 12:19 p.m.) > > > Review request for KDE Frameworks and David Faure. > > > Repository: kio > > > Description > ------- > > global.h is a public header, so not being more explicit with includes could > cause a build failure for consumers. This should probably go into kdelibs too. > > > Diffs > ----- > > src/core/global.h 7814a52c9656719d301ebd012434a53491ffe159 > > Diff: https://git.reviewboard.kde.org/r/116079/diff/ > > > Testing > ------- > > Builds. > > > Thanks, > > Michael Palimaka > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
