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
_______________________________________________
release-team mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/release-team

Reply via email to