Can I finally push this?

After finishing initial implementation I found out that QtPromise requires exceptions enabled. KDevelop seem to have exceptions disabled right now.

• Move the bracket.

Add IRuntime::findExecutable() API and make compilerprovider use it.

KAsync looks a bit unmaintained. On the other hand, QtPromise seems to be an active project. Should I start looking into the latter?

Onto master?

I started working on it.

I don't remember details of this revision, but at least it seems to do like how we agreed.

Remove API changes and just sort plugins list.

Address comments.

In D18296#437985, @apol wrote:

Overall this makes sense to me, this assumes though that there will never be a file ending with :digit, is that something we can live with?

Monthly bump.

In D17760#428860, @cullmann wrote:

Question: does any distro package that?

At least my openSUSE doesn't nor any other distro I know of, only thing I found was:

https://rpmfind.net/linux/rpm2html/search.php?query=libastyle-devel

Pingy-ping, bumpy-bump.

I have little Qt experience, why nested event loops are bad? What are options to avoid them?

Bump();

Oh, sorry, I forgot to press "Submit" on Phab and thought I posted ASan log here.

Remove code used for description.

In D5447#401247, @mwolff wrote:

you are right, this code should essentially do if (rt->findExecutable(compiler->path().isEmpty()) continue;, could you introduce that please?

In D5447#399235, @mwolff wrote:

the path of the compiler is now always the path of the compiler in the local host, which breaks when you have a runtime with a different setup.

Ping? Any chance to get this into 5.15?

Right.

Can I push this?

In D5447#393144, @apol wrote:

Let's look at this the other way around, what are you trying to fix?

Works great now, thanks!

In D17569#391929, @amhndu wrote:

In D17569#391807, @arrowd wrote:

I found the following minor issue:

When I just started KDevelop and open "Scratchpad" toolview, any action except "New Scratch" are greyed out. Even "Remove Scratch", as well as "Run Scratch". When I open any scratch, it turns back to normal, even if I again close all Sratchpad windows.

That's intended. The actions are all associated with the selected scratch in the toolview list. Switching the window to a different scratch also changes this selection, while closing a window keeps the selection.

But that's not related to your change, so please push it. Not sure where to, 5.3, I guess.

I found the following minor issue:

Restore another check.

The problem with current revision is that pages added in uicontroller.cpp:530 aren't sorted.

Fix docs, rename append* methods to add*.

Remove insert API and use append everywhere.

Sorry for being late to the party. Checked this on FreeBSD - no regressions.

Change the type from uint to int.

Restore a check.

In D18099#389132, @mwolff wrote:

+1, but it would be good if we could share this code...

In D17938#386985, @elvisangelaccio wrote:

I don't know, "cursorRow" and "cursorColumn" are pretty editor-specific. I'm not sure they make sense in the KRun API.

Yep, sorry, everything's alright.

Works great, good job!

In D17278#386387, @dmensinger wrote:

I also don't know why the icons don't show up. I have oriented myself on the code from the CMake plugin, and I don't know what I am doing different/wrong. Maybe KDevelop has to be installed in a system directory (/usr) for this to work?

Yep, that fixed the issue.

It now compiles and unit test passes, however my own quick test revealed following problem.

Strange. I don't have this menu item even with your patch.

Looks good to me.

Sorry for silly question, but where this change is reflected in KDevelop UI?

Tried this out on FreeBSD with KDevelop master.

Since 5.3.1 was released, can we get this in?

I have tried this out on master and it works for me. If no one objects in next few days, please push this.

Refresh diff and address comments.

Pass absolute path instead of the compiler name to createCompiler(). Remove strange check that was breaking tests.

Judging from current CI output, this has been fixed.

If the problem this patch solves is to have CMAKE_INSTALL_PREFIX to be set for newly-created projects, why not just add a configuration option to the CMake plugin?

In D16218#343348, @rjvbb wrote:

Oh, misunderstanding! I simply don't have a full KF5 build environment on FreeBSD yet. I'm running TrueOS in a VM on a system that isn't exactly powerful, so I'm waiting until "Project Trident" is released with a full KF5 desktop option.

In D16218#343326, @rjvbb wrote:

Re: the testing I did on FreeBSD: that's with a dedicated demonstrator; I cannot currently build KDevelop5 there.

FreeBSD+Clang 6 also works fine with this patch.