Re: Question regarding compatibility for kdecore and KDE4_ENABLE_FINAL
On Thursday 14 June 2012 17:54:58 Michael Pyne wrote: Sorry to be unclear -- that's exactly what the Mageia patch accomplishes. They only flip the exceptions bit for enable-final builds. If that sounds agreeable I intend on making that alteration and forwarding the patch to kde-packager. Sounds good to me (obviously). -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Question regarding compatibility for kdecore and KDE4_ENABLE_FINAL
On Tuesday 12 June 2012 20:42:28 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. The alternative would be to enable exceptions for all of kdecore only if enable-final is enabled. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Question regarding compatibility for kdecore and KDE4_ENABLE_FINAL
On Thursday, June 14, 2012 15:36:47 David Faure wrote: On Tuesday 12 June 2012 20:42:28 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. The alternative would be to enable exceptions for all of kdecore only if enable-final is enabled. Sorry to be unclear -- that's exactly what the Mageia patch accomplishes. They only flip the exceptions bit for enable-final builds. If that sounds agreeable I intend on making that alteration and forwarding the patch to kde-packager. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Question regarding compatibility for kdecore and KDE4_ENABLE_FINAL
On Thursday, June 14, 2012 20:18:04 Albert Astals Cid wrote: El Dijous, 14 de juny de 2012, a les 15:36:47, David Faure va escriure: On Tuesday 12 June 2012 20:42:28 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. The alternative would be to enable exceptions for all of kdecore only if enable-final is enabled. Is that binary compatible? If I'm understanding it right, it would add extra typeinfo classes for kdecore but would remain binary-compatible with older code. It is not mentioned at all in our TechBase binary compatibility page, which is even the #1 Google hit now. :) Also the flag itself is claimed as binary compatible (in the context of code that doesn't actually /use/ exceptions) in some discussion on the Qt dev list, by Olivier Goffart and Thiago Macieira [1] (both of whom I trust more than myself on this topic). Researching further, the GCC libstdc++ page [2] mentions that exception handling is part of the ABI, but I can only assume this is in the context of does this code throw exceptions or not as opposed to whether non-exception- using code would care about that flag. The GCC docs on -fexceptions talk about extra code to propagate exceptions and perhaps data size overhead but there's no specific warning regarding changing the ABI visible outside of the object file. The detailed GCC ABI spec is at [3] and it seems to me from my reading of it that the changes involved are changes to data included with the .o, changes in function implementations, and extra calls to the C++ runtime library... but no changes to symbol names, mangling, etc. As far as I can tell this change should be binary compatible. As an experiment I've recompiled kdecore here with exceptions and run KDevelop (which I think is a fair exercise of much of the breadth of kdecore technologies) and wasn't able to find any new issues from that change. [1] http://permalink.gmane.org/gmane.comp.lib.qt.devel/3681 [2] http://gcc.gnu.org/onlinedocs/gcc/Code-Gen- Options.html#Code%20Gen%20Options [3] http://sourcery.mentor.com/public/cxx-abi/abi-eh.html#cxx-abi Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Question regarding compatibility for kdecore and KDE4_ENABLE_FINAL
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 release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Question regarding compatibility for kdecore and KDE4_ENABLE_FINAL
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...). Regards, - Michael Pyne [1] http://svnweb.mageia.org/packages/cauldron/kdelibs4/current/SOURCES/kdelibs-4.8.4- correct-use-fexception-switch.patch?revision=260068view=markup signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
