[Ubuntu-touch-coreapps] Enabling Cmake for all the core apps

David Planella david.planella at ubuntu.com
Sun Feb 16 10:29:04 UTC 2014


On Sun, Feb 16, 2014 at 2:28 AM, Sergio Schvezov <
sergio.schvezov at canonical.com> wrote:

> Just a quick self follow up
>
> After removing my QtCreator config I get the Build/Ubuntu submenu and
> could explore the context of the problem a bit more.
>
> The desktop part can be resolved by changing the
> -set(DESKTOP_FILE "${PROJECT_NAME}_${APP_NAME}.desktop")
> +set(DESKTOP_FILE "${PROJECT_NAME}.desktop")
>
>
Thanks Sergio for looking into that. I think Nekhelesh's point was that
before the cmake migration it was much easier to test pure QML apps. Adding
cmake to the mix now requires a build step that needs to be done outside of
Qt Creator to generate the .desktop file.

Before, pressing Ctrl+F12 would just copy the files over to the device and
run the app. Granted, this would not test confinement, but for rapid app
development (and especially if it's an app that has been tested to work in
confinement) it is very convenient. App confinement could then be tested
with a click build and install before release.

But I think the main point here is that we've broken Qt Creator's workflow
for pure QML apps by introducing a build step as a requirement. Can we
still get the best of both worlds, perhaps by adapting Qt Creator's scripts
(e.g. the one that is called by pressing Ctrl+F12)?


> but to be honest, I think that qtcreator should look into the manifest to
> search for desktop files; this would allow for an easy transition to
> multiple apps per package namespace when it arrives.
>
>
Would you mind filing a bug for that? I also agree that resolving this
dynamically would be much better than hardcoding it to a given .desktop
file name.


> After hacking the desktop file that in I saw why it wanted to sed it:
> Exec=/usr/bin/export DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-LRsqEGysw5;
> APP_ID=com.ubuntu.clock qmlscene /home/phablet/dev_tmp/com.
> ubuntu.clock/ubuntu-sdk-13.10-armhf/click_package/share/qml/
> com.ubuntu.clock/com.ubuntu.clock.qml --desktop_file_hint=/home/
> phablet/.local/share/applications/com.ubuntu.clock.desktop
>
> It really should be installing the click package and using that so it uses
> upstart-app-launch to launch the application under confinement.
>
>
I'm not sure I can follow this one. Could you elaborate on what's needed to
do here, whether fix the cmake rules or the Qt Creator scripts?

Thanks.

Cheers,
David.


>
> On 15/02/14 21:48, Sergio Schvezov wrote:
>
>>
>> On 15/02/14 18:53, Nekhelesh Ramananthan wrote:
>>
>>> This is a request to revert the cmake transition for all the core apps
>>> since it is effectively blocking crucial application testing on the device
>>> through QtCreator. Before the cmake transition, my work flow comprised of
>>> implementing a patch/feature and then immediately testing it on the device
>>> by pressing Ctrl+F12 through Qtcreator. This made testing applications on
>>> the device quite easy. However as now, that no longer works since QtCreator
>>> now complains of a missing desktop file. I have tried fixing it by
>>> discussing it with zBenjamin and balloons on IRC, however at the end of the
>>> day this is still broken.
>>>
>>
>> What does ctrl+12 actually do? Does it require writable mode?
>>
>>
>>> I understand the major motivation for the cmake transition was to help
>>> easily build click packages (using click-buddy) and ready them for
>>> deployment to the device. However this is already easy enough to do in
>>> Qtcreator by simply pressing *Ctrl+F12* or rather using the "*Install on
>>> Device*" feature. As far as I understand, click-buddy doesn't help with
>>> running autopilot tests on the device either. I am really questioning the
>>> benefit of the cmake transition. If there is something that I am missing
>>> here, please do explain this to me.
>>>
>>
>> The other major motivation is to actually build click packages without
>> any hacks; as it was before all the packages had hardcoded paths for the
>> debs.
>>
>> If you run the autopilot tests in 'deb' mode you aren't really testing on
>> the target. To really test on the target you need the click package built,
>> installed, and run in confinement; using debs doesn't provide any of that.
>>
>> If the installing and testing requires writable mode on devices, that it
>> is also broken in my opinion.
>>
>>
>>> If you agree to the request, please submit patches reverting the commits
>>> done.
>>>
>>
>> If there's no hard coding, I'm fine. But there was serious hard coding
>> before.
>>
>> Although I say, do not despair :-)
>>
>> Immediate temp solution, is to make the build dir your actual branch in
>> Project/Build
>> http://ubuntuone.com/3FqnDSLJpg2CUSYAtwj2oM
>>
>> The reason you can't run locally in QtCreator is that, well, the system
>> doesn't know about out of source builds that easily; and something like
>> this is needed:
>>
>> https://code.launchpad.net/~sergiusens/ubuntu-clock-app/
>> run_from_qtcreator/+merge/206598
>>
>> For running autopilot and installing on the device I would need more info
>> on what you currently do.
>>
>>
>
> --
> Mailing list: https://launchpad.net/~ubuntu-touch-coreapps
> Post to     : ubuntu-touch-coreapps at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ubuntu-touch-coreapps
> More help   : https://help.launchpad.net/ListHelp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-quality/attachments/20140216/d1b462a9/attachment-0001.html>


More information about the Ubuntu-quality mailing list