Re: [kdelibs/frameworks] tier4/kde4support/src: Check for visibility support on gcc
On Sun, 01 Dec 2013 10:29:03 +0100, David Faure wrote:
On Thursday 28 November 2013 17:03:04 Aurélien Gâteau wrote:
Git commit 3bc8af3ec4477b5ff7acedd74b27d0d359e8bd1f by Aurélien
Gâteau.
Committed on 28/11/2013 at 17:02.
Pushed by gateau into branch 'frameworks'.
Check for visibility support on gcc
__KDE_HAVE_GCC_VISIBILITY was not defined in kdemacros.h.cmake,
causing
KDE_EXPORT and KDE_IMPORT to be no-ops, breaking builds of
kde-runtime,
kde-workspace and friends.
Don't know what to do for other compilers.
Looking at FindKDE4Internal.cmake in master, where this originally
comes from,
you need two more things:
* setting it to TRUE for Clang.
* actually passing the flag (-fvisibility=hidden) to the compiler !
Oups, good point :)
Interestingly tier1/kjs/src/kjs/CMakeLists.txt has another solution:
running
the test for all compilers. It also forgets to pass the flag to the
compiler,
though.
In fact, with the gcc version we require now, we might not even need
to run
this test, we could just set the flag? Then this can just become:
if (CMAKE_COMPILER_IS_GNUCXX OR CMAKE_CXX_COMPILER_ID STREQUAL
Clang)
set(__KDE_HAVE_GCC_VISIBILITY TRUE)
set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -fvisibility=hidden)
endif()
An alternative is the more feature-based approach, to support any
gcc-like
compiler automatically (e.g. icc?)
check_cxx_compiler_flag(-fvisibility=hidden
__KDE_HAVE_GCC_VISIBILITY)
if ( __KDE_HAVE_GCC_VISIBILITY)
set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -fvisibility=hidden)
endif()
[in which case we could also replace GCC with COMPILER]
I choose your second solution, but I kept the __KDE_HAVE_GCC_VISIBILITY
define. Since this code is in the KDE4Support framework, I think it
makes more sense to keep defines as close as possible to what was
available in KDE4, even if code using the __KDE_HAVE_GCC_VISIBILITY is
probably doing something wrong :)
Aurélien
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Using KCompressionDevice with QSaveFile
On Mon, Dec 2, 2013 at 10:31 PM, Dominik Haumann dhaum...@kde.org wrote:
Hi,
porting KSaveFile to QSaveFile, I stumbled into the following:
// This method has been made private so that it cannot be called,
// in order to prevent mistakes.
void QSaveFile::close()
{
qFatal(QSaveFile::close called);
}
In Kate, we use a QSaveFile saveFile(...); and then use
KCompressionDevice compDevice(saveFile, ...);
to write compressed data through compDevice into saveFile.
However, KCompressionDevice at some point always seems to call close(),
which
hits the qFatal().
Should I derive from QSaveFile and overwrite close() to call commit() ?
Am I missing something here?
Greetings,
Dominik
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Looks to me like it's either a bug on KCompressionDevice or QSaveFile.
Personally, I think it's rather odd that some public API call invariably
crashes (it's made private in QSaveFile, but it's still public on the
parent, so it's not very useful).
I'd say that this fix should go to Qt, but David will probably have a
better insight.
Mr Faure? :D
Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Changes to the CI system
Hi all, As some of you may be aware, the CI system was not performing builds yesterday. This was a necessary part of changes which were being made to switch it to using the branch groups methodology. These have now been completed and the system returned to normal service. External dependencies have also been split out, with projects now being required to specify which ones they require separately. Going forward into the future, this will allow each branch group to have it's own version of Qt, CMake, etc as needed. Due to the above however, some projects may now find that the incorrect branches are being built, or some dependencies are not available to them. Can people please check the relevant CI jobs for the projects they are interested in and verify that everything is correct? This applies particularly in the case of non-SC builds. Unfortunately there have been some casualties of these changes: artikulate/qt-mobility: Due to defects in the Qt Mobility build system it doesn't install itself properly, leading to the build failing. As such, Artikulate can no longer build. opencv: Attempting to build this with the current version of CMake causes the build to fail, indicating a behaviour change has taken place. I have patched around this to allow those projects dependent on opencv to compile successfully. If there are any issues with these changes, please let sysadmin know through the usual mechanisms. Thanks, Ben Cooksley KDE Sysadmin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
