[kde-dev-scripts] /: Add support for ninja to makeobj
Git commit cd599de58b44596a5e86a5fe560e2904ef5efe7f by David Faure.
Committed on 30/07/2015 at 12:54.
Pushed by dfaure into branch 'master'.
Add support for ninja to makeobj
Usage: alias make=makeobj, as usual.
This allows to do make and make install (etc.) in either the source
dir or the build dir, provided that $OBJ_REPLACEMENT is set.
CCMAIL: m...@vhanda.in, kde-core-devel@kde.org
M +28 -9makeobj
http://commits.kde.org/kde-dev-scripts/cd599de58b44596a5e86a5fe560e2904ef5efe7f
diff --git a/makeobj b/makeobj
index d4f82ad..e4d65d4 100755
--- a/makeobj
+++ b/makeobj
@@ -111,10 +111,14 @@ dir=.
cwd=$PWD
# No CMakeList and no Makefile (and no .pro file either)? Maybe we need to go
up then.
-while test ! -f CMakeLists.txt test ! -f Makefile; do
+while test ! -f CMakeLists.txt test ! -f Makefile ; do
if test `ls -1 *.pro 2/dev/null` test -n `ls -1 ../*.pro
2/dev/null`; then
break;
fi
+if test -f build.ninja; then
+file=build.ninja
+break;
+fi
dir=$dir/`basename \$PWD\`
cd ..
if test X$PWD = X/; then
@@ -173,12 +177,23 @@ if test ! -f $file; then
sed -e s,%ARCH%,\$_arch\,g | \
sed -e s,%OS%,\$_os\,g`
pwd=`echo $PWD | sed -e \$OBJ_REPLACEMENT\`
+ if test ! -e $pwd; then
+ echo no objdir found. Tried $pwd
+ exit 1
+ fi
if test ! -f $pwd/$file; then
- # No objdir found. But if make will work in srcdir, then go ahead;
might be a non-kde project.
+ # ninja requires building from the toplevel
+ cd -- $pwd
+ findup build.ninja
+ if test -n $_hit; then
+ pwd=`dirname $_hit`
+ file=build.ninja
+ fi
+ # No objdir with a Makefile found. But if make will work in srcdir,
then go ahead; might be a non-kde project.
test -f $pwd/GNUmakefile file=GNUmakefile
test -f $pwd/makefile file=makefile
if ! test -f $pwd/$file; then
- echo no objdir found. Tried $pwd
+ echo no Makefile or build.ninja found in $pwd
exit 1
fi
fi
@@ -199,13 +214,17 @@ if test -z $MAKE; then
fi
if test $using_new_unsermake -eq 1; then
MAKE=`command -v unsermake`
- if test ! -x $MAKE; then
- echo 'Makefile was created with unsermake, but there'
- echo 'is no unsermake in $PATH'
- exit 1
- fi
-else
+if test ! -x $MAKE; then
+echo 'Makefile was created with unsermake, but there'
+echo 'is no unsermake in $PATH'
+exit 1
+fi
+elif test -f Makefile; then
MAKE=$GMAKE
+elif test -f build.ninja; then
+MAKE=ninja
+else
+echo No Makefile or build.ninja found in $PWD!
fi
fi
LANG=en_US.UTF-8 $MAKE ${args[@]}
Notes from the Phabricator BoF
Hi all, thanks to Victor Blazquez, here are the notes from the Phabricator BoF. Feel free to add your comments and corrections. Feedback on Phabricator gathered outside the BoF from people who could not attend: - krita used for everything (reviews, tasks, mockups, even bugs); overwelmingly positive feedback from community - annoyance: big unified list of projects; confusing akonadinext used reviews, tasks; prefer tasks separate from bugs used internally in company too; also used sprint module - problem: in case of tasks coming from company phabricator and KDE phabricator, the line which reference the commit message will clash (same Tx), a different prefix is needed - (ervin said it's not a problem), as you could use the full URL of the task instead of just the task ID in the commit message. - annoyance: few rendering/usability bugs in the kanboard view with many tasks tanglu phabricator developers responsive thousands of projects handled in tanglu (no repositories yet) - problem: fast development can be a problem for updates (no real stable branch) Positive feedback from Ivan (kactivities) Positive feedback from Eike (konversation) BoF - Remove login form which is not LDAP - Change message and write something like Authenticate through identity.kde.org Uses of maniphest vs bugzilla - No migration for now (not the foreseeable future) Projects hierarchy (https://secure.phabricator.com/T3670) Custom view and notifications for groups - Dashboards - Share queries inside a group (check later) Can we push a patch through the webpage? (keep an eye on upstream) Do we want to reuse our CI system? https://wiki.jenkins-ci.org/display/JENKINS/Phabricator+Plugin When a new review is posted, trigger the CI, it needs some changes to the CI Lack of integration with CI is not a blocker Suggestion: It would be nice not need to test every patch (CI), to be discussed Support for arcanist is available for other plaftorms (Windows, MacOSx) Good feedback in general from the people who assisted Ciao -- Luigi
Re: Review Request 121755: Fix input focus for KDM's dialogs when GrabInput is not active
On Juli 30, 2015, 12:05 nachm., Thomas Lübking wrote: This is Qt4, right? ::activateWindow() should be equivalent to XSetInputFocus(display, winId(), XRevertToParent, X11-time); unless a) _NET_ACTIVE_WINDOW is listed in _NET_SUPPORTED on the root window (supposed to be set and withdrawn by window managers, crash on exit?) AND b) Qt::X11BypassWindowManagerHint is NOT set on the toplevel window OR c) the window is not mapped/waiting for a mapping notification = If the problem occurs, login aside (VT1 or ssh) and export DISPLAY=:0 xprop -root | grep _NET_ACTIVE_WINDOW If that's emtpy, focus setting fails on either qt_widget_private(tlw)-topData()-waitingForMapNotify (qt bug in event handling? missing XSync(dpy, false)? events are being processed after show) or X11-time being superseded by a more recent/future XSetInputFocus call (fixed by passing CurrentTime) If the feature /is/ listed, that's a bug caused by a crashing WM = setting Qt::X11BypassWindowManagerHint will likely be sufficient. This is Qt4, right? Yes. = If the problem occurs, login aside (VT1 or ssh) and export DISPLAY=:0 xprop -root | grep _NET_ACTIVE_WINDOW Hm, I don't seem to be able to get the properties of kdm's root window. After opening a new login session: ``` # export DISPLAY=:1 # xprop -root No protocol specified. xprop: unable to open display ':1' ``` On fresh boot: ``` # export DISPLAY=:0 # xprop -root Invalid MIT-MAGIC-COOKIE-1 keyxprop: unable to open display ':0' ``` If I kill kwin in a running KDE4 session, the feature is listed. But that's to be expected I suppose, if I understand you correctly. And focus changes when you move the mouse, which I think is undesirable at the login screen anyway (there are not really multiple windows, just modal dialogs). If the feature /is/ listed, that's a bug caused by a crashing WM = setting Qt::X11BypassWindowManagerHint will likely be sufficient. I will try if that helps. But just to avoid a misunderstanding here: this is about kdm's login greeter. There's no window manager running at all. - Wolfgang --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121755/#review83168 --- On Juli 29, 2015, 11:39 vorm., Wolfgang Bauer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121755/ --- (Updated Juli 29, 2015, 11:39 vorm.) Review request for kde-workspace, Thomas Lübking and Oswald Buddenhagen. Bugs: 268988 and 338018 http://bugs.kde.org/show_bug.cgi?id=268988 http://bugs.kde.org/show_bug.cgi?id=338018 Repository: kde-workspace Description --- [Commit d03df616](https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/d03df6169ecb291318e87099a346488c961fe1d6) made input grabbing optional in KDM. But without it, input dialogs do not correctly get focus and keyboard shortcuts don't work. KDM does call activateWindow() on opened dialogs, but this doesn't seem to have the desired effect without a window manager running. And if you hover the mouse over a widget, it visually looks like it has focus, but often it doesn't accept input anyway. This patch sets the input focus via XSetInputFocus() instead, this also has the positive side-effect that a widget retains the focus if you move the mouse away. Diffs - kdm/kfrontend/kfdialog.cpp 3f6fa84 Diff: https://git.reviewboard.kde.org/r/121755/diff/ Testing --- Tried all things mentioned in the bug reports, keyboard input and shortcuts work now in all cases. I also tested with onboard keyboards (xvkbd and kvkbd), both work fine. Before, kvkbd didn't work at all (the text input widget lost focus as soon as you moved the mouse to the OSK) and xvkbd only works if you forced the focus to the text input widget via its Focus button (from which this patch was inspired actually ;-) ). Other openSUSE users have tested this as well, and the patch is even part of openSUSE's official package since January. See also https://bugzilla.opensuse.org/show_bug.cgi?id=772344 Thanks, Wolfgang Bauer
Re: Review Request 121755: Fix input focus for KDM's dialogs when GrabInput is not active
On Juli 30, 2015, 10:05 vorm., Thomas Lübking wrote: This is Qt4, right? ::activateWindow() should be equivalent to XSetInputFocus(display, winId(), XRevertToParent, X11-time); unless a) _NET_ACTIVE_WINDOW is listed in _NET_SUPPORTED on the root window (supposed to be set and withdrawn by window managers, crash on exit?) AND b) Qt::X11BypassWindowManagerHint is NOT set on the toplevel window OR c) the window is not mapped/waiting for a mapping notification = If the problem occurs, login aside (VT1 or ssh) and export DISPLAY=:0 xprop -root | grep _NET_ACTIVE_WINDOW If that's emtpy, focus setting fails on either qt_widget_private(tlw)-topData()-waitingForMapNotify (qt bug in event handling? missing XSync(dpy, false)? events are being processed after show) or X11-time being superseded by a more recent/future XSetInputFocus call (fixed by passing CurrentTime) If the feature /is/ listed, that's a bug caused by a crashing WM = setting Qt::X11BypassWindowManagerHint will likely be sufficient. Wolfgang Bauer wrote: This is Qt4, right? Yes. = If the problem occurs, login aside (VT1 or ssh) and export DISPLAY=:0 xprop -root | grep _NET_ACTIVE_WINDOW Hm, I don't seem to be able to get the properties of kdm's root window. After opening a new login session: ``` # export DISPLAY=:1 # xprop -root No protocol specified. xprop: unable to open display ':1' ``` On fresh boot: ``` # export DISPLAY=:0 # xprop -root Invalid MIT-MAGIC-COOKIE-1 keyxprop: unable to open display ':0' ``` If I kill kwin in a running KDE4 session, the feature is listed. But that's to be expected I suppose, if I understand you correctly. And focus changes when you move the mouse, which I think is undesirable at the login screen anyway (there are not really multiple windows, just modal dialogs). If the feature /is/ listed, that's a bug caused by a crashing WM = setting Qt::X11BypassWindowManagerHint will likely be sufficient. I will try if that helps. But just to avoid a misunderstanding here: this is about kdm's login greeter. There's no window manager running at all. There's no window manager running at all. Yeah, got that ;-) xprop: unable to open display ':1' Ah, that's likely because the superuser has the X11 authority - try from a su login. And focus changes when you move the mouse That's the default X11 behavior, it will always behave like that (while unmanaged; and iirc it's suppressable by a config key/X switch) - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121755/#review83168 --- On Juli 29, 2015, 9:39 vorm., Wolfgang Bauer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121755/ --- (Updated Juli 29, 2015, 9:39 vorm.) Review request for kde-workspace, Thomas Lübking and Oswald Buddenhagen. Bugs: 268988 and 338018 http://bugs.kde.org/show_bug.cgi?id=268988 http://bugs.kde.org/show_bug.cgi?id=338018 Repository: kde-workspace Description --- [Commit d03df616](https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/d03df6169ecb291318e87099a346488c961fe1d6) made input grabbing optional in KDM. But without it, input dialogs do not correctly get focus and keyboard shortcuts don't work. KDM does call activateWindow() on opened dialogs, but this doesn't seem to have the desired effect without a window manager running. And if you hover the mouse over a widget, it visually looks like it has focus, but often it doesn't accept input anyway. This patch sets the input focus via XSetInputFocus() instead, this also has the positive side-effect that a widget retains the focus if you move the mouse away. Diffs - kdm/kfrontend/kfdialog.cpp 3f6fa84 Diff: https://git.reviewboard.kde.org/r/121755/diff/ Testing --- Tried all things mentioned in the bug reports, keyboard input and shortcuts work now in all cases. I also tested with onboard keyboards (xvkbd and kvkbd), both work fine. Before, kvkbd didn't work at all (the text input widget lost focus as soon as you moved the mouse to the OSK) and xvkbd only works if you forced the focus to the text input widget via its Focus button (from which this patch was inspired actually ;-) ). Other openSUSE users have tested this as well, and the patch is even part of openSUSE's official package since January. See also https://bugzilla.opensuse.org/show_bug.cgi?id=772344 Thanks,
Re: KSyCoca, Thread safety, and Cache invalidation
On Thursday, July 30, 2015 09:23:00 PM Mark Gaiser wrote: On Tue, Jul 28, 2015 at 4:28 PM, David Faure fa...@kde.org wrote: On Tuesday 14 July 2015 19:28:58 Thomas Lübking wrote: On Dienstag, 14. Juli 2015 19:00:14 CEST, Milian Wolff wrote: On Tuesday, July 14, 2015 11:49:25 AM David Faure wrote: On Friday 26 June 2015 18:03:00 Frank Reininghaus wrote: ... It has. Querying the current time repeatedly is quite costly, and often shows up in code that extensively uses timers, or QDateTime::currentDateTime() etc. But it's probably still cheaper than querying on-disk meta data in the worst case, esp. on old rotary disks. Actually, checking currentTime() is already the problem here (causing the IO for the timezone stuff), see http://marc.info/?l=kde-core-develm3533622526705w=1 (the 1st paragraph part of my comment somehow turned into a second-level quote) Comparing a monotic timer (QElapsedTime) is however - at least on linux - close to cost free PLUS: one can have an entirely free do not check again during this event cycle flag. I used QElapsedTimer in https://codereview.qt-project.org/122247 and the resulting performance improvements are amazing. kbuildsycoca5 is twice faster. Ohh, interesting! You're optimizing stuff :D I just ran kbuildsycoca5 --noincremental through kcachegrind without your patch to Qt and i do see one other quite big hot spot you might be interested in. In my case the profile collected 1.147.572.920 instructions. Nearly half of all those instructions (516.700.823) are spend in QMimeType::inherits. The cost per QMimeType::inherits call is 52.692 instructions (it's being called 9806 times). That function is heavy! I don't know exactly what it's doing since Qt is build in release mode without debug symbols (system package) so i only see lots of cycles being spend there, not what they are doing. You can ignore this message if QMimeType::inherits internally calls the method you optimized thus this function would be greatly improved already. Internally it's calling this function: http://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/mimetypes/qmimedatabas e.cpp#n216 It's improved by his patch, see https://codereview.qt-project.org/#/c/122247/ and the benchmark results therein. Bye -- Milian Wolff m...@milianw.de http://milianw.de signature.asc Description: This is a digitally signed message part.
Re: KSyCoca, Thread safety, and Cache invalidation
On Thursday 30 July 2015 21:23:00 Mark Gaiser wrote: You can ignore this message if QMimeType::inherits internally calls the method you optimized thus this function would be greatly improved already. It does. Why not apply existing known fixes before profiling for more issues? :) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
Re: KSyCoca, Thread safety, and Cache invalidation
On Tue, Jul 28, 2015 at 4:28 PM, David Faure fa...@kde.org wrote: On Tuesday 14 July 2015 19:28:58 Thomas Lübking wrote: On Dienstag, 14. Juli 2015 19:00:14 CEST, Milian Wolff wrote: On Tuesday, July 14, 2015 11:49:25 AM David Faure wrote: On Friday 26 June 2015 18:03:00 Frank Reininghaus wrote: ... It has. Querying the current time repeatedly is quite costly, and often shows up in code that extensively uses timers, or QDateTime::currentDateTime() etc. But it's probably still cheaper than querying on-disk meta data in the worst case, esp. on old rotary disks. Actually, checking currentTime() is already the problem here (causing the IO for the timezone stuff), see http://marc.info/?l=kde-core-develm=143533622526705w=1 (the 1st paragraph part of my comment somehow turned into a second-level quote) Comparing a monotic timer (QElapsedTime) is however - at least on linux - close to cost free PLUS: one can have an entirely free do not check again during this event cycle flag. I used QElapsedTimer in https://codereview.qt-project.org/122247 and the resulting performance improvements are amazing. kbuildsycoca5 is twice faster. Ohh, interesting! You're optimizing stuff :D I just ran kbuildsycoca5 --noincremental through kcachegrind without your patch to Qt and i do see one other quite big hot spot you might be interested in. In my case the profile collected 1.147.572.920 instructions. Nearly half of all those instructions (516.700.823) are spend in QMimeType::inherits. The cost per QMimeType::inherits call is 52.692 instructions (it's being called 9806 times). That function is heavy! I don't know exactly what it's doing since Qt is build in release mode without debug symbols (system package) so i only see lots of cycles being spend there, not what they are doing. You can ignore this message if QMimeType::inherits internally calls the method you optimized thus this function would be greatly improved already. Internally it's calling this function: http://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/mimetypes/qmimedatabase.cpp#n216
Re: Notes from the Phabricator BoF
Luigi Toscano wrote: Feedback on Phabricator gathered outside the BoF from people who could not attend: Were there no complaints about the fact that you can still not view anything at all without logging in? Kevin Kofler
Re: Notes from the Phabricator BoF
Il 30 luglio 2015 22:42:44 CEST, Kevin Kofler kevin.kof...@chello.at ha scritto: Luigi Toscano wrote: Feedback on Phabricator gathered outside the BoF from people who could not attend: Were there no complaints about the fact that you can still not view anything at all without logging in? No. I did not ask sysadmins, but I guess it's just an implementation details in the experimental phase. Other Phabricator instances are widely open; there is a good ACL system. Ciao -- Luigi
Re: Reviving Kaffeine
2015-07-20 3:01 GMT-03:00 Lasse Lindqvist lasse.k.lindqv...@gmail.com: I was thinking about reviving Kaffeine, but the previous developer hasn't responded to me. The projects irc channel and sites are dead, too. I was hoping someone here might be able to help me on this. Lasse Lindqvist Any objections to me marking Lasse as project manager in https://projects.kde.org/kaffeine ? -- Nicolás KDE Sysadmin Team (sort of)
Re: Review Request 121755: Fix input focus for KDM's dialogs when GrabInput is not active
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121755/#review83168 --- This is Qt4, right? ::activateWindow() should be equivalent to XSetInputFocus(display, winId(), XRevertToParent, X11-time); unless a) _NET_ACTIVE_WINDOW is listed in _NET_SUPPORTED on the root window (supposed to be set and withdrawn by window managers, crash on exit?) AND b) Qt::X11BypassWindowManagerHint is NOT set on the toplevel window OR c) the window is not mapped/waiting for a mapping notification = If the problem occurs, login aside (VT1 or ssh) and export DISPLAY=:0 xprop -root | grep _NET_ACTIVE_WINDOW If that's emtpy, focus setting fails on either qt_widget_private(tlw)-topData()-waitingForMapNotify (qt bug in event handling? missing XSync(dpy, false)? events are being processed after show) or X11-time being superseded by a more recent/future XSetInputFocus call (fixed by passing CurrentTime) If the feature /is/ listed, that's a bug caused by a crashing WM = setting Qt::X11BypassWindowManagerHint will likely be sufficient. - Thomas Lübking On Juli 29, 2015, 9:39 vorm., Wolfgang Bauer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121755/ --- (Updated Juli 29, 2015, 9:39 vorm.) Review request for kde-workspace, Thomas Lübking and Oswald Buddenhagen. Bugs: 268988 and 338018 http://bugs.kde.org/show_bug.cgi?id=268988 http://bugs.kde.org/show_bug.cgi?id=338018 Repository: kde-workspace Description --- [Commit d03df616](https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/d03df6169ecb291318e87099a346488c961fe1d6) made input grabbing optional in KDM. But without it, input dialogs do not correctly get focus and keyboard shortcuts don't work. KDM does call activateWindow() on opened dialogs, but this doesn't seem to have the desired effect without a window manager running. And if you hover the mouse over a widget, it visually looks like it has focus, but often it doesn't accept input anyway. This patch sets the input focus via XSetInputFocus() instead, this also has the positive side-effect that a widget retains the focus if you move the mouse away. Diffs - kdm/kfrontend/kfdialog.cpp 3f6fa84 Diff: https://git.reviewboard.kde.org/r/121755/diff/ Testing --- Tried all things mentioned in the bug reports, keyboard input and shortcuts work now in all cases. I also tested with onboard keyboards (xvkbd and kvkbd), both work fine. Before, kvkbd didn't work at all (the text input widget lost focus as soon as you moved the mouse to the OSK) and xvkbd only works if you forced the focus to the text input widget via its Focus button (from which this patch was inspired actually ;-) ). Other openSUSE users have tested this as well, and the patch is even part of openSUSE's official package since January. See also https://bugzilla.opensuse.org/show_bug.cgi?id=772344 Thanks, Wolfgang Bauer
