- User Since
- Apr 18 2015, 11:52 AM (248 w, 1 d)
Fri, Jan 17
where "full" would also need to mean "clean fresh build dirs" :) so that the codegenerator is triggered to be run, as the current cmake code seems to not inject a build dep between generator instance and generated files, so a new version does not trigger regeneration. Something that could also get a fix perhaps, IIRC other tools have such a dep.
This morning it was found e.g. on opensuse build server (but reproduced by me locally) that this change broke KMyMoney & KDevelop, who now start to fail e.g. with (using VERBOSE=1 make)
[ 38%] Generating kcfg_custombuildsystemconfig.h, kcfg_custombuildsystemconfig.cpp cd /home/koder/Kode/kdegit/build/kf5/extragear/kdevelop/kdevelop/plugins/custom-buildsystem && /home/koder/System/opt/kf5/lib64/libexec/kf5/kconfig_compiler_kf5 /home/koder/Kode/kdegit/kf5/extragear/kdevelop/kdevelop/plugins/custom-buildsystem/kcfg_custombuildsystemconfig.kcfg /home/koder/Kode/kdegit/kf5/extragear/kdevelop/kdevelop/plugins/custom-buildsystem/kcfg_custombuildsystemconfig.kcfgc -d /home/koder/Kode/kdegit/build/kf5/extragear/kdevelop/kdevelop/plugins/custom-buildsystem/ No entries. make: *** [plugins/custom-buildsystem/CMakeFiles/kdevcustombuildsystem.dir/build.make:71: plugins/custom-buildsystem/kcfg_custombuildsystemconfig.h] Fehler 1
See https://phabricator.kde.org/source/kdevelop/browse/master/plugins/custom-buildsystem/ for the respecive kfg files.
Thu, Jan 16
No one any opinion? Guess most people have not run into the need to do pre-processor switches for the doc generation, and also never seen DOXYGEN_SHOULD_SKIP_THIS before.
Hi. When introducing the deprecation macros to a lib with ecm_generate_export_header, one also needs to help kapidox & ecm_add_qch. Sadly this was only discovered later, so it is also missing from the first set of such commits introducing the use of ecm_generate_export_headerwhich you might have taken as template :)
Wed, Jan 15
Seen while forking the Message classes for KDevelop for some shell-level message area :) https://invent.kde.org/kde/kdevelop/merge_requests/87
Was confused initially by the old code, and then found it also less µ-optimized ;)
Last night's run of api.kde.org generation with kapidox locally patched with this change worked again,
So unless there are objections will push then latest next WE, though happy to have people give green light before :)
Tue, Jan 14
fix comment locale -> filesystem encoding
D22836 was tried before to fix this, but later it was found this still did not work on api.kde.org. At that time I had added some local patches on api.kde.org itself, but not getting further at one point forgot about things sadly.
Brown paper bag for me: if one changes code, they should also see to trigger
that code, in this case passing the --depdiagram-dot-dir arg to
For now, given @bcooksley's comment going to try some simple change to 'from kapidox.depdiagram import gvutils', this is a pattern found elsewhere in the old code. Will do a local patch to the checkout on the server and see if this has any effect on next cron job run. So far that also worked for all the 3 situations I tested (local python3 & python2, python2 on server test env).
To add to my confusion, running the unpatched version works with my local 2.7.17 python interpreter (checked with print (sys.version)) and worse, running things manually on api.kde.org in some test subdir also works with its 2.7.15...
Because the very user api.kde.org right now in production still uses python2 sadly. And replacing that server with something modern is sadly not a few-hours job, still waiting for someone to spend the weeks on getting a substitution done.
D26652 now up as proposal to fix this
No python developer myself, but from patterns seen I guess the imports should have some
if sys.version_info.major < 3: // python2 import style else: // python3 import style
Hi. Sadly api.kde.org failed to pick this change up until yesterday, as I had forgotten a change in the local checkout on my last work on the server, which then blocked the update via scripted git pull.
That I fixed partially yesterday, making sure latest KApiDox is run on api.kde.org, but that showed that gentoo(?) server running api.kde.org does not like yet this new code:
Traceback (most recent call last): File "/home/api/kapidox/src/kapidox_generate", line 110, in <module> main() File "/home/api/kapidox/src/kapidox_generate", line 106, in main copyright=kde_copyright) File "/home/api/kapidox/src/kapidox/hlfunctions.py", line 108, in do_it dot_files, tmp_dir) File "/home/api/kapidox/src/kapidox/generator.py", line 646, in generate_diagram with_qt=with_qt) File "/home/api/kapidox/src/kapidox/depdiagram/generate.py", line 156, in generate db.populate(dot_files, with_qt=with_qt) File "/home/api/kapidox/src/kapidox/depdiagram/frameworkdb.py", line 175, in populate fw = parser.parse(tier, dot_file) File "/home/api/kapidox/src/kapidox/depdiagram/frameworkdb.py", line 115, in parse dot_data = preprocess(dot_file) File "/home/api/kapidox/src/kapidox/depdiagram/frameworkdb.py", line 75, in preprocess for node_handle in gvutils.get_node_list(graph_handle): NameError: global name 'gvutils' is not defined
Mon, Jan 13
While touching this file, you might want to fix this file and make it self-contained by also having a include(CMakeParseArguments) at the begin, could be done as direct commit, no review needed IMHO :)
Hotfix pushed: bfcc2363174804160e7da06b47128b7bad10cf09
Will do a quick hot fix then to unbreak builds, proper solution can be discussed later (only had my first coffee right now).
By setting -DKF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x054200 for the build of the lib, you effectively disable KCOMPLETION_ENABLE_DEPRECATED_SINCE(5, 66), and thus hide this class from any builds. Which makes kdelibs4support fail e.g., cmp. https://build.kde.org/job/Frameworks/job/kdelibs4support/job/kf5-qt5%20SUSEQt5.12/86/
No further need, thanks. I got the assist in your previous reply already I was looking for :)
Where is removing sound capabilities from KNotifications discussed? That would be a loss, as one does not always stare at the screen, but also walks around (think lab) and would like some audio options to be notified about certain things one set as important to get back to the device.
Not knowning the discussion I might misunderstand something, so please point me to that place :) Actually, given mobile phones also happily make use of sound to notify (given they share the same fate of not always being looked at), I expect to get this wrong ;) But just in case...
Sun, Jan 12
Some API (docs) nitpicks :)
No insight myself, but would trust you you know what you are doing here :) and it also matches what I just read on https://reproducible-builds.org/docs/archives/
Some similar macro definitions used by other projects, as I found by doing some random grepping over my system includes:
- Q_QDOC & Q_CLANG_QDOC
- BOOST_DOXYGEN_INVOKED & lots of similar
Sat, Jan 11
Fri, Jan 10
Thu, Jan 9
Thanks for having had a look again, and confirming that I was not seeing things wrongly half-asleep still :) I am about to touch this code in some days anyway, and would twist things then as needed.
I just came across this logic (for reasons) and wonder if the logic does what you intended with the patch:
given the const auto canonicalPathToCheck = checkPathIsFile ? pathInfo.canonicalFilePath() : QStringLiteral("");, when checkPathIsFile is false, canonicalPathToCheck is an empty string.
Wed, Jan 8
BTW, not invoking yet another process with the qdbus executable, but instead sending off the D-Bus message drectly might also increase reaction time.
Do I correctly understand from the previous patches that spectacle should now be single instance application? In that case it might really make more sense to investigate to use the official D-Bus Activation part of the desktop file specification instead of manual D-Bus message sending hackery. That part had been designed for such use cases from what I can tell.
Looking at the actual code being touched here: Is qdbus actually a good choice here? Can it be expected to be installed by default? Would dbus-send not be the better option, as it seems part of the normal D-Bus demon implementation package?
Tue, Jan 7
KMainWindowPrivate::CompressCalls being used here still exposes a small issue, as this opens a small time window where the state is not catched before a xmlgui client change happens, so some finalizeGUI might (in theory) still use old state data, as autoSaveSettings is not yet triggered on e.g. xmlgui client removal.
Something to look into next. But this here should improve things already a lot.
Mon, Jan 6
Sun, Jan 5
Fri, Jan 3
Thu, Jan 2
Have not tested. Looks good code-wise, is what I would have done.
Thanks. Okay, so the old symbol is still there, and with that info I looked some more, and indeed the ::endl symbol is not declared in the header qtextstream.h, but only defined (and exported) in the source file qtextstream.cpp. Having 3 variants now not make sense to me on first look, but perhaps a result of some incomplete approach in Qt 5.14... oh well...
Wed, Jan 1
@mlaurent Hm, is there a chance ABI got broken by that respective code in Qt 5.15 when it comes to the non-Qt-namespaced variants of the methods? Unless I misread, those deprecated ones are now in the QTextStreamFunctions namespace. And which might be source compatible, due to the using namespace QTextStreamFunctions; in the header, but does that help with the namespace being reflected in the exported symbols?
Ah, I looked at the "dev" branch only and missed that it is possibly already pre-Qt6, no longer base for any future Qt5 branches, right?
Indeed things look differently in the 5.15 branch, where the old variant is tagged deprecated, I now see.
@mlaurent Bonne année :) Hm, are we sure that endl is namespaced with Qt:: in 5.15 already? Isn't that rather Qt6 only?
Sun, Dec 29
Some comments while flying over the code due to being triggered by phab message, but no in-detail review and analysis of approach done, lack of concentration currently, sorry.