cmake in Flathub kdevelop

[Igor Kushnir]

On 2023-05-25 00:00, Jonathan Verner wrote:
> Hi,
> 
> Since kdevelop allows configuring the cmake binary in the CMake plugin settings
> as well as per-project (in the "Advanced" CMake configuration), I think this is
> a bug.

You are right.

> I just cursorily looked over the code and I think the problem might be the
> following. Didn't have time to check, though...
> 
> in the `checkForNeedingConfigure` (in cmakeutils.cpp) when the `addBuildDir`
> lambda is called in the case that the current build path is non-empty. It
> passes `{}` as the `cmakeExecutable` argument, and the lambda then overwrites
> the `cmake executable` setting. When
> `CMakeBuildDirChooser::setCMakeExecutable` is called a few lines later, it is
> passed the result of `currentCMakeExecutable` which correctly reads the
> "global" setting, but then finds out that the "per-project setting", which is
> set to {}, now returns the "default",  e.g. the result of a path-based search
> for `cmake` (in the current runtime). If these differ (and they do, in Ryan's
> case) the project setting will be chosen, which is the default cmake.
> 
> Perhaps removing the call to `CMake::setCurrentCmakeExecutable`  would be
> a fix?
> 
> Or replace the last `{}` in the lambda call with
> `CMakeBuilderSettings::self()->cmakeExecutable().toLocalFile()` ?

The `if (!currentRuntime->buildPath().isEmpty()) {` check in 
checkForNeedingConfigure() returns true only in case the Flatpak runtime is 
active, because all other runtimes return an empty path from buildPath(). So 
this could only be the bug if the Flatpak version of KDevelop automatically 
activates the Flatpak plugin (which it shouldn't). Then the bug needs to be 
fixed in the Flatpak plugin to prevent its auto-activation, not in the CMake 
plugin. I guess when the user manually selects the Flatpak runtime, using the 
CMake executable inside the Flatpak environment might be desirable. Aleix may 
have implemented this behavior in 
https://commits.kde.org/kdevelop/kdevelop/df9ce19157624920bc7847b347ab65ab3cdbc7bf 
deliberately.

Ryan, could you check which runtime is selected in Flatpak-KDevelop's main menu 
=> Run => Runtime: ... ?

> The `usebuilder.cpp` call should also be fixed, but that, I think, is less
> urgent, as it affects language support for CMakeList.txt files only...

The initCommands() function in usebuilder.cpp initializes a global variable, 
possibly for good reason. Getting the currently configured CMake executable from 
there can be difficult or slow as the single user of the global variable 
UseBuilder::startVisiting() runs in a background thread.

> Cheers,
> 
> Jonathan

Regards,
Igor