cmake in Flathub kdevelop

[Igor Kushnir]

Including Ryan, who is likely not subscribed to the mailing list.

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

On 2023-05-25 12:19, Igor Kushnir wrote:
> 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