From kde-core-devel Wed Jun 13 16:13:48 2012 From: Alexander Neundorf Date: Wed, 13 Jun 2012 16:13:48 +0000 To: kde-core-devel Subject: Re: Question regarding compatibility for kdecore and KDE4_ENABLE_FINAL Message-Id: <201206131813.49090.neundorf () kde ! org> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=133960429707881 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--Boundary-01=_9wL2PYhydUNaN1T" --Boundary-01=_9wL2PYhydUNaN1T Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit On Wednesday 13 June 2012, Michael Pyne wrote: > Hi all, > > Bug 301419 has been reported against kdelibs due to a build failure when > KDE4_ENABLE_FINAL is used, introduced by some commits of mine to perform > even more sanity checking in the KSharedDataCache. > > These commits use exceptions (as are already used in khtml) since they are > actually "the right tool" in the context of where they are used, and > because refactoring everything to use error codes everywhere (ECE) would > have risked introducing more bugs. > > In order to minimize the changes to kdecore I only added the CMake magic to > enable exceptions for only kshareddatacache.cpp. This doesn't work when > KDE4_ENABLE_FINAL is used, as the project-wide CXXFLAGS are used in that > case. > > The Mageia devs have a proposed patch [1] to enable exceptions for all of > kdecore, which fixes the issue. Is it acceptable for me to go this route? > The only real alternative this late in the game is to back out the sanity > checks to the 4.8.3 status or to explicitly say that KDE4_ENABLE_FINAL > will not work for this tarball although it worked for 4.8.3, both of which > I consider less desirable. But I don't want to make the change if there > are good reasons to avoid it. > > Longer term (for frameworks) KSharedDataCache could be split into its own > tier if necessary (it only really depends on Qt and KStandardDirs, which > is now also in Qt...). In KDE frameworks, i.e. next gen kdelibs, ENABLE_FINAL will not be supported anymore at all. AFAIK gcc now actually has a mode to do interobject optimizations, so with this mode enabled (which we currently don't), ENABLE_FINAL should not be necessary anymore. So, personally I do not really care much about ENABLE_FINAL. Alex --Boundary-01=_9wL2PYhydUNaN1T Content-Type: text/html; charset="iso-8859-6" Content-Transfer-Encoding: 7bit

On Wednesday 13 June 2012, Michael Pyne wrote:

> Hi all,

> Bug 301419 has been reported against kdelibs due to a build failure when

> KDE4_ENABLE_FINAL is used, introduced by some commits of mine to perform

> even more sanity checking in the KSharedDataCache.

> These commits use exceptions (as are already used in khtml) since they are

> actually "the right tool" in the context of where they are used, and

> because refactoring everything to use error codes everywhere (ECE) would

> have risked introducing more bugs.

> In order to minimize the changes to kdecore I only added the CMake magic to

> enable exceptions for only kshareddatacache.cpp. This doesn't work when

> KDE4_ENABLE_FINAL is used, as the project-wide CXXFLAGS are used in that

> case.

> The Mageia devs have a proposed patch [1] to enable exceptions for all of

> kdecore, which fixes the issue. Is it acceptable for me to go this route?

> The only real alternative this late in the game is to back out the sanity

> checks to the 4.8.3 status or to explicitly say that KDE4_ENABLE_FINAL

> will not work for this tarball although it worked for 4.8.3, both of which

> I consider less desirable. But I don't want to make the change if there

> are good reasons to avoid it.

> Longer term (for frameworks) KSharedDataCache could be split into its own

> tier if necessary (it only really depends on Qt and KStandardDirs, which

> is now also in Qt...).

In KDE frameworks, i.e. next gen kdelibs, ENABLE_FINAL will not be supported anymore at all.

AFAIK gcc now actually has a mode to do interobject optimizations, so with this mode enabled (which we currently don't), ENABLE_FINAL should not be necessary anymore.

So, personally I do not really care much about ENABLE_FINAL.

Alex

--Boundary-01=_9wL2PYhydUNaN1T--