On my last blog post I discussed about how some assumptions such as the platform developed on can affect our development. We need to minimize it by empowering the developers with good tools so that they can develop properly. To that end, I introduced runtimes in our IDE to abstract platforms (much like on Gnome’s Builder or Qt Creator).
There are different platforms that we’ll be developing for and they need to be easily reachable when coding and testing. Both switching and interacting transparently with the different platforms.
To that end I implemented 4 approaches that integrate different runtimes:
- Docker, allows you to develop directly against virtually any system. This is especially interesting because it enables to reproduce the environment our users are having: behavior on execution and project information (i.e. the imports are the ones from the target rather the ones on our local system). Docker is a wide-spread technology in the cloud, I hope many developers will see the value in integrating the deployed environment into the IDE while they are coding.
- Flatpak, is a solution that targets specifically desktop Linux applications. We are talking about distributing bundled applications to users, there we have the opportunity to integrate the tooling specifically to that end: from fetching dependencies to testing on other devices (see videos below).
- Android, as you know it’s something I’ve been pushing for years. Finally we are getting to a space where the IDE can help get some set up troubles out of the way.
- The local host, i.e. what we have now.
And remember KDevelop is extensible. Do you want snapcraft?, vagrant?, mock? Contributions are very welcome!
If there’s something better than a list of technologies and buzzwords, that’s videos. Let’s see why this could change how you develop your software.
One development, any platform
We get to develop an application and switch back and forth the target platform we are developing for.
Here I put together a short video that tests Blinken on different platforms:
- Executes the application locally (ArchLinux)
- Executes the application on OpenSUSE Tumbleweed through Docker
- Executes the application on Neon development through Docker
One development, any device
Using the right SDK is not enough proof that the application will work as expected on every device, especially those our users will be using. Being able to easily send our application to another device to test and play around with is something I had needed for longtime. Especially important when we need to test different form factors or input devices.
In this video we can see how we can easily test an application locally and when it works just switch to Android and send to the device for proper test on the smaller touch screen.
Here we can see how we can just test an application by executing it remotely on another device. This is done by creating a bundle of the application, sending it to the device where we want to test it and executing it there.
You can’t deny it. You’ve wanted to fix things in the past, but you couldn’t be bothered with setting up the development environment. Both Flatpak and Docker offer the possibility to maintainers to distribute recipes to set up development platforms that can and should be integrated so that we can dedicate this 1 hour in the week-end to fixing that bug that’s been annoying us rather than reading a couple of wikis and – oh, well, never mind, gotta make dinner.
We can do this either by providing the flatpak-builder json manifest (disclaimer: the video is quite slow).
Or a Dockerfile.
You can try this today by building kdevelop git master branch, feedback is welcome. Or wait for KDevelop 5.2 later this year. 🙂
this is great news, especially for kde software! The fact that, in order to fix a tiny bug in kdevelop, you need to build the entire stack from git makes “1 hour in the week-end” bugfixes impossible.
I really hope there will be precompiled devel runtimes available one day (I know of docker-kdesrc-build, but its still wrapped in a python script and takes hours to compile), so i can just download the latest kdevelop-devel runtime, fix that one bug which has been annoying me for the last months and file a PR – All before i have to go and make dinner.
Keep up the great work!
Really great news. Thanks for your work.
> this is great news, especially for kde software! The fact that, in order to fix a tiny
> bug in kdevelop, you need to build the entire stack from git makes “1 hour in the
> week-end” bugfixes impossible.
I have the same issue 🙂 Having a docker images where the current master is precompiled – ideally with ccache – would be nice. But I think even without ccache this image would be huge (my build folder has 6 GiB). On the other hand, it would be interesting to just keep the ccache files and delete the build directory before building the dev image.
I currently work for a big project where all libraries needed for development are installed and shipped with a docker images. I wonder what the intended workflow is when I want the C++ background parser to find all relevant libraries. Some people who use Eclipse in the project copy the library includes from the docker image to a dedicated directory on the host machine and tell the IDE to look in this directory first. This seems not ideal. With Netbeans you need a SSH access to the docker container and then it finds the sources to feed the C++ parser. What is the way to go with KDevelop. Ideally, I would connect KDevelop to a container and it uses Docker commands to look for the source and libraries there. What do you think?
thank you for bringing this feature to KDevelop. I am interested in the docker runtime, but never managed to get that right. Could you be so kind as to clarify things up for me. Here is what I observe.
Whenever I want to develop against a docker runtime KDevelop starts up the container but once the current job, e.g. source code parsing on opening a project, is done, the container is destroyed. Therefore, when I change e.g. a line of code in order for the parser to pick that change up a now docker container is started. I monitor that with `docker ps`. Since this can’t be right, I used an entrypoint for the container with a `while sleep 1; do :; done` in order to prevent the container from finishing. Well, I have the feeling that this is irritating KDevelop since now the initial code parser does not finish any more.
So here is my question: How do I need to prepare my dockerfile in order to play nice with the KDevelop Docker runtime feature?
Thank you so much!
Just wanted to share my recent work on Plasma Mobile SDK – it’s containerized Sysroot for cross-compile for Manjaro ARM.
Integrates with QtCreator nicely – build from IDE, deploy is possible.
Things need to be documented and announced yet, but still it’s already usable.
Any feedback are welcome!