Re: cmake in Flathub kdevelop

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

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

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



May 25, 2023, 05:22 by [email protected]:

> Including Ryan, who is likely not subscribed to the mailing list.
>
> Ryan, could you check which runtime is selected in Flatpak-KDevelop's mai=
n menu =3D> Run =3D> 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 `addBuil=
dDir`
>>> lambda is called in the case that the current build path is non-empty. =
It
>>> passes `{}` as the `cmakeExecutable` argument, and the lambda then over=
writes
>>> 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", wh=
ich is
>>> set to {}, now returns the "default",=C2=A0 e.g. the result of a path-b=
ased 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 b=
e
>>> a fix?
>>>
>>> Or replace the last `{}` in the lambda call with
>>> `CMakeBuilderSettings::self()->cmakeExecutable().toLocalFile()` ?
>>>
>>
>> The `if (!currentRuntime->buildPath().isEmpty()) {` check in checkForNee=
dingConfigure() returns true only in case the Flatpak runtime is active, be=
cause all other runtimes return an empty path from buildPath(). So this cou=
ld only be the bug if the Flatpak version of KDevelop automatically activat=
es 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 plug=
in. I guess when the user manually selects the Flatpak runtime, using the C=
Make executable inside the Flatpak environment might be desirable. Aleix ma=
y have implemented this behavior in https://commits.kde.org/kdevelop/kdevel=
op/df9ce19157624920bc7847b347ab65ab3cdbc7bf deliberately.
>>
>> Ryan, could you check which runtime is selected in Flatpak-KDevelop's ma=
in menu =3D> Run =3D> Runtime: ... ?
>>
>>> The `usebuilder.cpp` call should also be fixed, but that, I think, is l=
ess
>>> urgent, as it affects language support for CMakeList.txt files only...
>>>
>>
>> The initCommands() function in usebuilder.cpp initializes a global varia=
ble, possibly for good reason. Getting the currently configured CMake execu=
table 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
>>