cmake in Flathub kdevelop

[roundup976 at tutanota.com]

Igor, first off, thanks for getting back to me.

The Runtime is set to Host System.   The only other option I see is Android.  This is in the Flatpak version of kdevelop.

Thanks
Ryan
-- 
 Sent with Tutanota, enjoy secure & ad-free emails. 



May 25, 2023, 05:22 by igorkuo at gmail.com:

> 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
>>