Re: Review Request 109449: Deprecate KWindowSystem::doNotManage and make it no-op

ttp://git.reviewboard.kde.org/r/109449/#comment21726> Why not remove it completely? - Stephen Kelly On March 12, 2013, 8:09 a.m., Martin Gräßlin wrote: > > --- > This is an automatically generated e-mail. To reply

Re: Please update extra-cmake-modules, kdelibs (and plasma-frameworks)

Alexander Neundorf wrote: >> That may be a broader issue, but I don't think this is a problem for KDE. >> For the KDE frameworks, we will use the KF5:: prefix. > > If we start doing it here, our developers will assume this is the way to > do it and take this everywhere, at their workplaces, to oth

Re: Please update extra-cmake-modules, kdelibs (and plasma-frameworks)

Alexander Neundorf wrote: > I also would like to get a concensus on what to use, that's why I posted > this issue here. > I don't think it is KDE style to reach concensus by forcing the majority > vote on the maintainer and just dismiss his arguments. Yes, sorry. I was too quick with that. > >

Re: K_EXPORT_PLUGIN

Aaron J. Seigo wrote: > On Tuesday, February 26, 2013 15:40:38 Aaron J. Seigo wrote: >> right now in libplasma2 we have definitions like this: > > anyone? :) > You might get a knowledgeable response on the Qt development mailing list. Thanks, Steve. _

Re: Please update extra-cmake-modules, kdelibs (and plasma-frameworks)

Alexander Neundorf wrote: > On Thursday 28 February 2013, David Faure wrote: > ... >> ... which means it will also fail at link time, not at cmake time. >> So I don't see the point in this change. I'd must rather write KF5::Solid >> than ${Solid_LIBRARIES}, where I can never remember if that's LIB

Re: qt5 includes

Treeve Jelbert wrote: > I am trying to build kf5libs using the latest extra-cmake-modules and > yesterday's qtbase. > > At first I encountered a problem regarding qt support for SSL. I > bypassed that and then got several compile errors. > > They all seemed to be related to > > #include > > I

Re: Finding dependencies in config files

Alexander Neundorf wrote: > On Saturday 16 February 2013, Alexander Neundorf wrote: >> On Saturday 16 February 2013, Stephen Kelly wrote: >> > commit 6bf0ad9fc7807f341ca924235d2f1e54b8038881 >> > Author: Alex Neundorf >> > Date: Sat Feb 9 18:50:06 2013 +0

Re: QT5_BUILD can go, also from itemmodels ?

Alexander Neundorf wrote: > Hi, > > the cmake variable Qt5_BUILD is still used in a few places, I guess it can > go ? > > Alex Yes, it can go if the code that it covers actually works with Qt 5. If not, I don't see a reason to change it to something else. Thanks, Steve. ___

Re: Build failed in Jenkins: kdelibs_frameworks_qt5 #403

Alexander Neundorf wrote: > On Saturday 16 February 2013, Stephen Kelly wrote: >> KDE CI System wrote: >> > -- Performing Test __KDE_HAVE_FPIE_SUPPORT >> > -- Performing Test __KDE_HAVE_FPIE_SUPPORT - Success >> >> I don't think this option makes sense

Re: Build failed in Jenkins: kdelibs_frameworks_qt5 #403

Alexander Neundorf wrote: > Hi Stephen, > > On Saturday 16 February 2013, Stephen Kelly wrote: >> KDE CI System wrote: >> > CMake Error at >> > /srv/jenkins/install/linux/x64_64/g++/qt5/kdesupport/extra-cmake- >> >> modules/master/share/ECM-0.

Finding dependencies in config files

commit 6bf0ad9fc7807f341ca924235d2f1e54b8038881 Author: Alex Neundorf Date: Sat Feb 9 18:50:06 2013 +0100 kguiaddons: check that kconfig has been found in the Config.cmake file Alex diff --git a/staging/kguiaddons/kguiaddonsConfig.cmake.in b/staging/kguiaddons/kguiaddonsConfig.c

Re: Build failed in Jenkins: kdelibs_frameworks_qt5 #403

KDE CI System wrote: > -- Performing Test __KDE_HAVE_FPIE_SUPPORT > -- Performing Test __KDE_HAVE_FPIE_SUPPORT - Success I don't think this option makes sense either. By default, Qt requires that PIE is used, and it sets Qt5_POSITION_INDEPENDENT_CODE if it does need to be used. CMake already

Re: Build failed in Jenkins: kdelibs_frameworks_qt5 #403

KDE CI System wrote: > CMake Error at > /srv/jenkins/install/linux/x64_64/g++/qt5/kdesupport/extra-cmake- modules/master/share/ECM-0.0.7/kde-modules/KDECompilerSettings.cmake:404 > (message): Qt compiled without support for -fvisibility=hidden. This will > break plugins and linking of some applic

Re: Review Request 108889: Add QML_INSTALL_DIR variable to KDE pathes

Stephen Kelly wrote: > Thiago Macieira wrote: >> A quick check shows that the cmake generated files are completely wrong >> already for when someone plays with the dir options. They don't take >> --bindir into account, for example. > > Did you check this, or ar

Re: Review Request 108889: Add QML_INSTALL_DIR variable to KDE pathes

Thiago Macieira wrote: > A quick check shows that the cmake generated files are completely wrong > already for when someone plays with the dir options. They don't take > --bindir into account, for example. Did you check this, or are you guessing? Thanks, Steve.

Re: khtml uses qx11info_x11 without checking for qtx11support

David Faure wrote: > On Sunday 10 February 2013 23:35:53 Stephen Kelly wrote: >> Especially as I see on the wiki link you posted, the recommendation is to >> configure it with tests. Why do we instruct people build all Qt tests? >> That's pure timewasting. > > OK

Re: kdelibs[frameworks] build failure in kwindowsystem and others

Sebastian Kügler wrote: > I'm getting the following build errors in kdelibs[frameworks] since > yesterday. It seems the CI system doesn't pick it up (or hasn't yet): > > [ 22%] Building CXX object > tier1/kwindowsystem/src/CMakeFiles/kwindowsystem.dir/kwindowsystem_x11.cpp.o > /home/sebas/kf5/sr

Re: khtml uses qx11info_x11 without checking for qtx11support

Alexander Neundorf wrote: > On Sunday 10 February 2013, Stephen Kelly wrote: >> Treeve Jelbert wrote: >> > /var/git/kf5/khtml/khtmlview.cpp:36:26: fatal error: qx11info_x11.h: No >> > such file or directory >> > compilation terminated. >> > >>

Re: khtml uses qx11info_x11 without checking for qtx11support

Treeve Jelbert wrote: > /var/git/kf5/khtml/khtmlview.cpp:36:26: fatal error: qx11info_x11.h: No > such file or directory > compilation terminated. > > Also qtx11support is broken, still uses obsolete QT_{BEGIN,END}_HEADER Please make sure you are using codereview.qt-project.org:qt/qtx11extras.

Re: Separating everything ?

Kevin Ottens wrote: > On Wednesday 6 February 2013 20:12:49 Treeve Jelbert wrote: >> Why not create tier{1,2} repos immediately, if they can build >> standalone? > > We're still moving classes in there. It's not yet ready for splitting. Additionally, tier1 libraries might not remain tier1 librar

Re: repository changes for plasma2/frameworks5

Kevin Ottens wrote: > On Monday 28 January 2013 18:54:12 Stephen Kelly wrote: >> Marco Martin wrote: >> > Most important, what is the less messy git way to do it? >> >> As we discussed on IRC, it may be better to split plasma out into its own >> repo n

Re: Review Request 108487: Make kjsembed build on Qt5 rather than on Qt4

> On Jan. 20, 2013, 7:04 p.m., Stephen Kelly wrote: > > kjsembed/kjsembed/slotproxy.cpp, line 68 > > <http://git.reviewboard.kde.org/r/108487/diff/2/?file=108067#file108067line68> > > > > Is this the common way to get at that stuff now? In Qt itself I

Re: Review Request 108495: Make kimgio compile on Qt5

> On Jan. 19, 2013, 11:16 p.m., Christoph Feck wrote: > > As far as I know, you need to add some JSON stuff to make plugins work with > > Qt 5. The JSON file is optional, but you do need to use the Q_PLUGIN_METADATA macro. - Stephen --

Re: Review Request 108487: Make kjsembed build on Qt5 rather than on Qt4

ttp://git.reviewboard.kde.org/r/108487/#comment19738> Is this the common way to get at that stuff now? In Qt itself I mean. - Stephen Kelly On Jan. 19, 2013, 10:29 p.m., Jon Severinsson wrote: > > --- > This is an automatically generated e-mail.

Re: Qt5 is required

David Faure wrote: > On Saturday 19 January 2013 19:07:39 Stephen Kelly wrote: >> David Faure wrote: >> > Stephen, you mentionned a script to get rid of the ifdefs for Qt4/Qt5, >> > do you have that at hand, or does it need to be written? >> >> It needed t

Re: Qt5 is required

David Faure wrote: > Stephen, you mentionned a script to get rid of the ifdefs for Qt4/Qt5, do > you have that at hand, or does it need to be written? It needed to be adapted from another script that I have. Actually I needed two scripts - one to handle #if < 5.0.0, and another for #if >= 5.0.0.

[kdelibs/frameworks] /: Bump required ecm version.

Git commit 6013607009a9bb04860e4a743ad35f4dfae8860f by Stephen Kelly. Committed on 19/01/2013 at 17:21. Pushed by skelly into branch 'frameworks'. Bump required ecm version. The ecm version was bumped in November, but the frameworks requirement was not. An indication for me that that

Re: Review Request 108487: Make kjsembed build on Qt5 rather than on Qt4

487/#comment19713> If it requires Qt5UiTools to work, then check for it. All positive checks for QT5_BUILD are now redundant, so you can remove them. - Stephen Kelly On Jan. 19, 2013, 12:54 p.m., Jon Severinsson

Re: Config files for frameworks (Was: KArchive for Qt4)

Alexander Neundorf wrote: > On Tuesday 18 December 2012, Stephen Kelly wrote: >> Alexander Neundorf wrote: >> > yes, but forgot to answer. >> > No strong reason here. The options containing "HAVE" are based on >> > whether that thing existed on the

Re: Config files for frameworks (Was: KArchive for Qt4)

Alexander Neundorf wrote: > At work, we set the RPATH manually. We know the limited number of > libraries we link against, we want to have full control over the RPATH. I > would be surprised if we would be the only ones. Anyone handling RPATH manually knows about get_filename_component :). > > I

Re: Config files for frameworks (Was: KArchive for Qt4)

Alexander Neundorf wrote: > yes, but forgot to answer. > No strong reason here. The options containing "HAVE" are based on whether > that thing existed on the system where the library was built. This one is > independent on whether udisk2 existed on that system, so I thought "USE" > might be bette

Re: Config files for frameworks (Was: KArchive for Qt4)

Alexander Neundorf wrote: > On Tuesday 18 December 2012, Stephen Kelly wrote: >> Alexander Neundorf wrote: >> > Please have a look at the current solidConfig.cmake.in. >> > This is mostly as I think it should be (the include-guard is still >> > missing)

Re: Config files for frameworks (Was: KArchive for Qt4)

Alexander Neundorf wrote: > As providers of a library we should not enforce how people use CMake, i.e. > whether they use the automatic INSTALL_RPATH_USE_LINK_PATH or whether they > want to decide manually. We can * make the common things easy (we don't need to do anything and people can use I

Re: Config files for frameworks (Was: KArchive for Qt4)

Alexander Neundorf wrote: > Please have a look at the current solidConfig.cmake.in. > This is mostly as I think it should be (the include-guard is still > missing). > > solidConfig.cmake > # solidConfig.cmake provides information about the installed solid > # library. > #is supported solid_

Re: Config files for frameworks (Was: KArchive for Qt4)

Alexander Neundorf wrote: > On Thursday 29 November 2012, Stephen Kelly wrote: >> Alexander Neundorf wrote: >> > The code for creating a Config.cmake file is not trivial, but IMO also >> > not boilerplate, and Stephen agreed in Berlin that this will have to be >

Re: removing use of qt names which are removed in qt5

Treeve Jelbert wrote: > Qt5 has now removed some functions which were previously deprecated. > > the attached script will scan an entire git branch and fix any use of > the following cases: Thanks. Actually most of those things are still there, but deprecated and wrapped in #if QT_DEPRECATED_SI

Re: Review Request: QtWebkit is now split in QtWebKit and QtWebKitWidgets

--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107438/#review23361 --- Ship it! Ship It! - Stephen Kelly On Dec. 12, 2012, 3:31

Re: Config files for frameworks

Alexander Neundorf wrote: >> There is no point in keeping cmake files looking exactly as they do now >> if we can instead remove noisy/redundant information. That is progress. >> If it was 2006 what would you choose? > > I would prefer if both ways would stay valid and continue to work as they > d

Re: Config files for frameworks

Alexander Neundorf wrote: >> > Retraining all our users that using include_directories() is wrong >> > doesn't sound good to me. >> >> I think re-training is the cost of simplicity, and it's worth it. >> >> You only expect to have to use include_directories() because you have >> always had to. So

Re: Config files for frameworks (Was: KArchive for Qt4)

Alexander Neundorf wrote: > I still think it is not a good idea that > > target_link_libraries(foo KF5::widgetsaddons) > > also sets include dirs for the target foo. > Should I discuss that again on cmake-devel ? It would seem more appropriate than here, but I think it's already decided. > >>

Config files for frameworks (Was: KArchive for Qt4)

Alexander Neundorf wrote: > The code for creating a Config.cmake file is not trivial, but IMO also not > boilerplate, and Stephen agreed in Berlin that this will have to be done > individually be every project. This is the added > threadweaverConfig.cmake.in and the call to > configure_package_con

Re: Using qplatformdefs.h

David Faure wrote: > KF5-with-Qt5 compilation is currently broken because we can't locate > qplatformdefs.h > > This used to come from this line: > tier1/kcoreaddons/src/CMakeLists.txt: 74: > include_directories(${QT_MKSPECS_DIR}/default) # for qplatformdefs.h That line can be removed I think.

Re: [PATCH 1/3] Drop KDE_NO_PHONON, Phonon works on Qt5 now.

David Faure wrote: > Hi Jon, > > What's the status on phonon-for-Qt5? If all changes got merged in, maybe > this patch can be applied to kdelibs-frameworks? I think KDE_NO_PHONON still has value anyway. It makes it easier to do things in the frameworks branch because you don't have to build a

Re: KArchive for Qt4

Sune Vuorela wrote: > On 2012-11-18, Stephen Kelly wrote: >> Sune Vuorela wrote: >>> I'm currently trying to get threadweaver built separately (for qt4). and >>> the build system is way too complicated. and way too complex. and way >>> too wrong. >&

Re: KArchive for Qt4

David Faure wrote: > After my presentation on KDE Frameworks at the Dev Days, the obvious > question "where do we download this from" came up -- especially for > KArchive. > > So I took some time afterwards and prepared a self-contained > KArchive-for-qt4 release. > > This pointed out some inter

Re: KArchive for Qt4

David Faure wrote: >> Also, if you don't use the feature_summary() function from >> FeatureSummary.cmake, then you don't have to use >> set_package_properties(). > > Oops, oversight. > I just looked through the zip. Do you have an updated version with some issues fixed/removed? >> You use the

Re: KArchive for Qt4

Alexander Neundorf wrote: > The code for creating a Config.cmake file is not trivial, but IMO also not > boilerplate, and Stephen agreed in Berlin that this will have to be done > individually be every project. This is the added > threadweaverConfig.cmake.in and the call to > configure_package_con

Re: KArchive for Qt4

Alexander Neundorf wrote: >> the variable for includes is not complete. you include most bits by >> doing include , but threadweaver/foo includes >> "threadweaver_export.h", so the threadweaver_INCLUDE_DIR variable isn't >> complete enough. I needed >> include_directories(${threadweaver_INCLUDE_DI

Re: KArchive for Qt4

Alexander Neundorf wrote: >> this is because the string "threadweaver" refers to the imported target >> with the name "threadweaver". > > I would also see this as a hint that we should use a namespace for the > exported target, so the line wouldn't be > > set(threadweaver_LIBRARY threadweaver) >

Re: KArchive for Qt4

Sune Vuorela wrote: > On 2012-11-15, David Faure wrote: >> This pointed out some interesting issues, especially in the cmakelists. I >> removed the dependency on ECM, and as a result I saw many things for >> which I thought "this should be in upstream cmake". Especially the >> LIB_INSTALL_DIR stu

Re: Review Request: Fix ObjectDescriptionModel<*>::staticMetaObject initialization on Qt5.

David Faure wrote: > I can't really review this code (without much research), but I completely > support this "let's not let the fixes die for lack of review" strategy. > My strategy so far has been 'Don't bother doing the Qt 5 porting (to kdesupport). Let the maintainers decide when they care

Re: Review Request: When building Phonon five against Qt5, use qmake to detect Qt installation paths.

David Faure wrote: > CMakeLists.txt > > > Steve? Something for you to add to the Qt5 cmake files? I don't know. Should phonon really install phonon plugins into the paths for *Qt* plugins and qml files? Is that a leftover from when phono

Build failure with Qt 5

Hi, A recent patch of mine makes the frameworks branch fail to build with Qt 5: https://codereview.qt-project.org/#change,37624 I made it not possible to emit the aboutToQuit signal, which apparently KApplication tries to do. I don't know the X code that KApplication is using which tries to e

Re: Review LibKdeAccessibilityClient

Kevin Ottens wrote: > The first point could be a problem I guess if you aim at releasing before > KDE Frameworks 5.0 as ECM is not widespread in distros yet. ECM is also not released yet, to be clear. We can and will change macro and function signatures, remove things entirely and generally mak

Re: ECMQtFramework.cmake, version header and ECMWriteVersionHeader.cmake

Alexander Neundorf wrote: > and I'm also not sure we should use the term "Framework" here, since this > may very well be mixed up with OSX frameworks by cmake users). OSX users might get themselves confused about the meaning and ownership of the word 'framework', but I don't think that should be

Re: Improved export-sets in CMake

Alexander Neundorf wrote: > On Monday 04 June 2012, Stephen Kelly wrote: >> > Do you have time to finish this feature? > > Ok, cmake 2.8.9 has been released. > > How does actually the interface for this proposed extension look like ? I wonder too. Yury do you still h

Re: Review Request: Port from KApplication KCmdLineArgs to QApplication in unit tests.

Jeremy Paul Whiting wrote: > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/105897/ > --- > > (Updated Aug. 6, 2012, 6:53 p.m.) >

Re: Definition of done - warning

Benjamin Port wrote: > Currently when we build kdelibs there are lots of warnings. That's why I > suggest to add a remove all warnings in the definition of done. > > But we can't remove all warnings, indeed some warnings come from moc file > (deprecated slots) and from unit test where we want to

Re: KDE_EXPORT is needed

Patrick Spendrin wrote: > One issue I have found was that KDE_EXPORT and KDE_IMPORT went missing. > > KDE_EXPORT and KDE_IMPORT are needed e.g. if you want to export a > function from a plugin (you never want to import it) meaning that it is > needed for K_EXPORT_PLUGIN to work properly. In that

Re: KDE_EXPORT is needed

ke? If it works, we can apply it to a copy of the two affected files which we keep in frameworks until 2.8.10 is out. Thanks, Steve. >From fb5a85f299b1a22d5fcc7d61cde55f0469210c7a Mon Sep 17 00:00:00 2001 From: Stephen Kelly Date: Wed, 4 Jul 2012 16:28:46 +0200 Subject: [PATCH] Add a DECL_EXPO

Re: Windows patches

Patrick Spendrin wrote: > Hi everybody, > > I am now half way through building kdelibs frameworks branch on windows. > > Some things I want to mention: > - most unittests are console applications on Windows and so they need to > be linked against the stub library qtmain.lib. I committed a patch

[kdelibs/frameworks] tier1/kwindowsystem/src: The config file appears in public headers, so it must be installed.

Git commit 39486d4854fabdf5e74a0f7c26404c2a90b46c1d by Stephen Kelly. Committed on 24/05/2012 at 23:31. Pushed by skelly into branch 'frameworks'. The config file appears in public headers, so it must be installed. Otherwise downstreams can't build. We probably need a bette

Re: libqtmimetypes ?

Alexander Neundorf wrote: >> Why though? Just to get tier2 libraries building standalone? What you >> propose isn't good enough that it gets the tier2 libraries into a final >> state as you say, so why bother? > > It is good enough to make it possible to build them standalone, and have > the suppo

Re: [kdelibs/frameworks] tier2/kconfig/autotests/kconfig_compiler: Fix qt4 build.

David Faure wrote: > No idea why this line was in "qt5 only", it's not related to Qt... It didn't work with my Qt 5 build, and I found it commented out (it worked for everyone else in a Qt 4 build up to now). I wrapped it in QT5_BUILD in cc1aa5dfe02bf9f277f36b61b8f737a524e5f2f6. Thanks, Steve

Re: Qt5 cmake stuff

Alexander Neundorf wrote: > On Monday 14 May 2012, David Faure wrote: >> On Monday 14 May 2012 23:13:44 Alexander Neundorf wrote: >> > if (NOT TARGET Qt5::Core) >> > >> > add_library(Qt5::Core SHARED IMPORTED) >> > >> > endif() >> >> Thanks, that works, and is MUCH simpler too ;-) >> >> Any

Re: libqtmimetypes ?

Stephen Kelly wrote: > Or there could be issues in the Qt 5 CMake files which are critical to > KF5, but which have not been found yet for the same reasons > (configurations different to what I use). Then they might not be fixed > until Qt 5.1. > > Building against Qt 4 will

Re: libqtmimetypes ?

Alexander Neundorf wrote: > On Sunday 13 May 2012, Stephen Kelly wrote: >> Alexander Neundorf wrote: > ... >> > This means either we need to put a lot of work in the buildsystem, to >> > handle all cases correctly (and clean up afterwards again), or we don't &

Re: libqtmimetypes ?

Alexander Neundorf wrote: >> We'll still keep it possible to build with Qt 4 for some months yet. >> Probably as long as it's still useful. Currently it is useful because the >> output of unit tests can show whether failures result from frameworks >> code or Qt 5 changes. >> >> What I mean though

Re: libqtmimetypes ?

Alexander Neundorf wrote: > On Sunday 13 May 2012, Stephen Kelly wrote: >> Alexander Neundorf wrote: >> > On Sunday 13 May 2012, Stephen Kelly wrote: >> >> Alexander Neundorf wrote: >> >> > Hi, >> >> > >> >> > in libi

Re: libqtmimetypes ?

Alexander Neundorf wrote: > On Sunday 13 May 2012, Stephen Kelly wrote: >> Alexander Neundorf wrote: >> > Hi, >> > >> > in libinqt5/src/ there is a libqtmimetypes. >> > This contains again a complete project. >> > Is this supposed to be bui

Re: kcoreaddons doesn't compile standalone ?

Alexander Neundorf wrote: > On Sunday 13 May 2012, Kevin Ottens wrote: >> On Sunday 13 May 2012 12:24:55 Alexander Neundorf wrote: >> > On Sunday 13 May 2012, David Faure wrote: >> > > But one big module with independent subprojects that don't get >> > > compiled out of the box, sounds like a majo

Re: libqtmimetypes ?

Alexander Neundorf wrote: > Hi, > > in libinqt5/src/ there is a libqtmimetypes. > This contains again a complete project. > Is this supposed to be buildable standalone, or always only inside > libinqt5 ? > It used to buils standalone, but Rolf Eike Beer moved it around for his own packaging re

Re: state of tier2/, i.e. kauth and kconfig ?

Kevin Ottens wrote: > On Saturday 12 May 2012 13:59:45 Alexander Neundorf wrote: >> what is the current state of kauth and kconfig ? >> Are they supposed to be done, i.e. buildable standalone ? > > Yes, they're supposed to be done. They very likely can't find their own dependencies (the ones fro

Re: building libkdeqt5staging standalone

Alexander Neundorf wrote: > Hi, > > in libkdeqt5staging/CMakeLists.txt there is a call > find_package(inqt5) > > When I try to build libkdeqt5staging standalone this fails, because it > finds neither a Findinqt5.cmake nor a inqt5Config.cmake. > > How is this supposed to work, should there be a

Re: setting EXECUTABLE_OUTPUT_PATH in tier1/ tests ?

Stephen Kelly wrote: > David Faure wrote: > >> On Thursday 10 May 2012 23:21:55 Stephen Kelly wrote: >>> David Faure wrote: >>> >> Now we don't do that anymore. >>> >> So for Windows the dlls and the exes have to go into the same >>

Re: setting EXECUTABLE_OUTPUT_PATH in tier1/ tests ?

David Faure wrote: > On Thursday 10 May 2012 23:21:55 Stephen Kelly wrote: >> David Faure wrote: >> >> Now we don't do that anymore. >> >> So for Windows the dlls and the exes have to go into the same >> >> directory. >> > >> &g

Re: setting EXECUTABLE_OUTPUT_PATH in tier1/ tests ?

David Faure wrote: >> Now we don't do that anymore. >> So for Windows the dlls and the exes have to go into the same directory. > > And how will the libs be found on Unix, given that they are under lib/ and > not bin/? > > Putting all executables in bin doesn't remove the need for wrapper > scri

Re: Removing WinCE support

Alexander Neundorf wrote: > Hi, > > KDAB made kdelibs in some way work with Win CE. > > Now Win CE is a very different OS, and IMO we should not even strive to > port KDE to such OSs (limitations in address space per process, static > linking only, etc.). This is not anti-MS, this also applies f

Re: Qt component QtConcurrent ?

Alexander Neundorf wrote: > Hi, > > in tier1/solid/CMakeLists.txt the component "QtConcurrent" is requested > from FindQt4.cmake. > Is QtConcurrent a separate component of Qt ? > FindQt4.cmake coming with cmake 2.8.8 fails with an error in this case. It seemed to work for me before. Maybe I had

Re: Usage of COMPONENT in ECMQtFramework.cmake

Alexander Neundorf wrote: > Hi, > > the COMPONENT argument for install() is used in different ways in the > frameworks branch. > > This is done: > > set(ECM_TARGET_DEFAULT_ARGS > # EXPORT ${PROJECT_NAME}LibraryTargets > RUNTIME DESTINATION "${BIN_INSTALL_DIR}" COMPONENT ${PROJECT_NAME} >

Re: LIBRARY_TYPE in ECMQtFramework.cmake

Alexander Neundorf wrote: > Hi, > > in ECMQtFramework.cmake there is the line > > set(LIBRARY_TYPE SHARED) > > which is used later on in the libraries e.g. like this: > > add_library(itemmodels ${LIBRARY_TYPE} ${itemmodels_SRCS}) > > What is this good for ? > It is not in the cache, so it is

Re: kdelibs splitting: looking back at april and going forward

Kevin Ottens wrote: > * kidletime, the only one not started, somewhat independent though, Dario > is the maintainer. I notice that this one uses a lot of X11. Is porting from xlib to xcb part of considering something like this 'done'? KWindowSystem still uses xlib, and was moved out of staging

Re: kdelibs splitting: looking back at april and going forward

Kevin Ottens wrote: > Hello, > > May is upon us, flowers are blooming, temperature is rising... time for > another quick recap on the progresses (or lack thereof) in the kdelibs > splitting department. I'll also present the revised backlog for May and > following months. > > > > # What happene

Re: Modified build system for itemmodels

Stephen Kelly wrote: > If it is, then I'd resubmit my proposal to have: > > include(ItemModelsConfigCommon.cmake) > > inside ItemModelsConfig.cmake, and generate it in the CMakeLists.txt And by the way I also think we've covered all the discussion points needed in thi

Re: Modified build system for itemmodels

Alexander Neundorf wrote: > URL and DESCRIPTION belong to the used project, so they are candidates for > being set in the Config.cmake file. > But there are two downsides of setting them in the Config file: > - the information where to get the package is not present when the package > is not presen

Re: Modified build system for itemmodels

Alexander Neundorf wrote: >> kf5_do_common_stuff() # TODO: Get better name > > Where should this macro come from ? > Should this be expanded from @PACKAGE_INIT@ or from an included file ? > From an included file would be bad, this would add compatibility issues > for the included file. You mean i

Re: kdeui splitup (widgets)

David Faure wrote: > kcompletionwidgets would only contain KLineEdit+KComboBox, and the > completion classes. That's really not much imho. If we put KLineEdit in its own framework, that would already be 4 public classes (KLineEdit, KCompletionBase, KCompletion, KCompletionMatches). A more real

Re: Modified build system for itemmodels

Alexander Neundorf wrote: > attached are prototypes. > > Please have a look (ignore the version-related stuff for now). > > The Use-file is not there anymore, and the Config.cmake.in file is not > there anymore. > Instead it is now generated using the new function > ecm_write_basic_package_config

Re: Modified build system for itemmodels

Alexander Neundorf wrote: >> >> Why do we need a use file? Qt 5 doesn't create or install them. >> > >> > You added it, so I thought you want to have it. >> > If not, let's remove it. >> >> Yes. > > Ok. I'll remove them in the next days. > Are they used anywhere already ? Thanks. Nope they're n

Re: Modified build system for itemmodels

Alexander Neundorf wrote: >> > This IMO easily qualifies as "magic" most developers will not >> > understand, they will not know where these files come from, what they >> > are good for, what they should contain. >> > >> > By having the >> > write_basic_package_version_file() >> > configure_packag

Re: Modified build system for itemmodels

Alexander Neundorf wrote: > Hi, > > attached is a patch for kdelibs/tier1/itemmodels/. > > It removes the usage of ECMQtFramework.cmake and uses instead the (new) > cmake features directly. > > The biggest difference is that itemmodels_version.h.in, > itemmodelsConfig.cmake.in and itemmodelsUseF

Re: kdeui splitup (widgets)

David Faure wrote: > On Sunday 29 April 2012 13:24:43 Stephen Kelly wrote: >> > for independent reusable widgets, such as: >> > KSeparator, KHBox/KVBox, KLed, KArrowButton, KCapacityBar (if the >> > dependencies on kcolorscheme and kstyle can be sorted out), >&g

Re: kdeui splitup (widgets)

David Faure wrote: > It seems to me that we haven't properly defined yet, what goes where. Yes I agree, I brought this up a few weeks ago too. > > Looking at kdeui and at the current kwidgets, while filling in > http://community.kde.org/Frameworks/Epics/Reduce_class_duplication > I came up with

Re: Where to put KDE Frameworks cmake stuff...

Alexander Neundorf wrote: >> > Now that it seems the shared-install-dirs feature can be removed, this >> > could be good enough. >> > It would imply that e-c-m will be updated relatively often >> >> Why would it need to be updated relatively often? Why does the removal of >> the shared-install-dir

Re: Where to put KDE Frameworks cmake stuff...

Alexander Neundorf wrote: > I thought more about it. > How about that: > > find_package(KF5 COMPONENTS kcore kwidgets kitemmodels) > > searches in the normal cmake way for kcoreConfig.cmake, using > CMAKE_PREFIX_PATH and all that. Additionally automatically also using > KDEDIRS. > > Once it has

Re: Where to put KDE Frameworks cmake stuff...

Alexander Neundorf wrote: > White: no kdelibs at all anymore, but 20 separate libraries. Gnome world ? I'm not sure it will be so granular. A lot of our code is for the benefit of 'KDE' only, and not useful for Qt developers looking for re-usable libraries. The code that is useful already, we

Re: Where to put KDE Frameworks cmake stuff...

Alexander Neundorf wrote: >> I do not understand why we can not install multiple versions of a library >> to one prefix. > > E.g. because we don't have versioned include dirs, so there can be only > one version in one prefix (talking about development installations). Right, you were talking about

Re: Where to put KDE Frameworks cmake stuff...

Hi, I'm not certain we're understanding what the other is saying, and these emails are already too long and covering too many different subjects. I'll just select a few things to respond to. > But, whenever I try to introduce versioned install dirs, nobody here wants > to have them, > so cur

Re: Where to put KDE Frameworks cmake stuff...

Alexander Neundorf wrote: >> instead of maintaining a list of 'known' components. This would make the >> FindKDEFrameworks some kind of 'reflector' for finding frameworks which >> adds consistency of versions etc. > > I thought about this. > IMO it is a good thing to have a hardcoded list of known

Re: Where to put KDE Frameworks cmake stuff...

Alexander Neundorf wrote: > Hi, > > so here's my proposal: > > * we will have a separate KF5 package, which will be a build-time > requirement for building KDE frameworks libraries. It will offer the > following features > ** KDE approved compiler settings > ** KDE conforming install dirs > **

<    1   2   3   4   5   >