Coming in 4.13: Improvements in the build plugin

Kate comes with a build plugin, which supports running make, or ninja,  or actually any arbitrary command directly from within Kate. This is obvisouly  useful when using Kate as development editor, and this plugin has seen several improvements for the 4.13 release.

A small change, but for affected developers a major improvement, is that Kate  can now parse warning and error messages from the Intel compilers, icpc and icc.
So for those of you using icpc, Kate can now automatically jump to the line of code which caused the error. Actually you don’t have to wait for 4.13 for this, it is already available since 4.12.3.

Beside that, there are improvements which benefit all users of the build plugin. Let’s start with a screenshot, which already shows one of the major changes.

Build plugin showing the list of targets and the Build-menu


Up to 4.12, it was possible to create multiple “targets”, and each of these targets could contain a “Build” command, a “Clean” command and a “Quick” command.  As of 4.13, the build plugin is not limited anymore to these three commands. As can be seen in the screenshot, every “target set” can now  contain an arbitrary number of actual targets.
They are listed in a table widget. To add a target, click the green “plus”-button in the lower right. This will  append a target to the end of the list. It can be edited by simply double clicking it (or pressing F2 while keyboard focus is in the table).
To delete a target, click the “minus”-button right next to the “plus”
One of the targets can be marked as the “default” target. This will typically be  the target which runs “make all”. Additionally one target can be marked  as the “clean” target, this will typically be “make clean”. For these two special  targets separate keyboard shortcuts can be assigned, so they are always  quickly available.

A whole set of actions which can be bound to shortcuts can be seen here:

Configuring keyboard shortcuts for the build plugin


Now to the actually interesting part: building something.
There are multiple ways how to start building a target.

The default and the clean targets can be built directly using keyboard shortcuts, in the screenshot above I assigned F8 to the default target.
To build another than the default target, you can select the target you want in the table and then build it by clicking the blue “check”-button next to the “plus” and “minus” buttons.
For keyboard users, there is a quick-select dialog. It shows a list with the names of all targets, which can be filtered by typing part of the target name. That’s a really quick way to build any of the available targets. Here’s a screenshot:

The Quick-select dialog for building a target


Once building has started, the output is displayed in the log view.
As can be seen, there is only one output tab left, where the “level of detail” can be adjusted using a slider. While building, the plugin automatically switches to the log display.

Build plugin showing the output while building.


Also new, there is now a simple status display, which tells you which target is currently being built or was built previously.
Next to it, there is yet another way to start a build, the “Build again” button. Once some target has been built, using this button the same target can be built again. Oh, and there is now also a button to cancel a build, in case you forgot the assigned keyboard shortcut.

When building has finished, the output tab automatically switches to a parsed output mode, which lists the warning – and error messages. By double clicking on one of them or using the keyboard shortcut of your choice, I assigned F9,  you can jump directly to the line of code which caused the error.

Build plugin showing the parsed errors after the build failed.

All that together, should make the build plugin even more useful than before.
Have fun compiling ! :-)


8 thoughts on “Coming in 4.13: Improvements in the build plugin

  1. Lovely :-) Great work Alex, makes the Build plugin much more flexible (and means I can do less sh which makes things simpler.)

    Where is it getting that long list of targets from? They look like they’ve come from the cmake file; is there a particular format we can use in response to eg: make kate-targets # that would enable integration?

    Also, what about project specifiers for say:
    make proj=%p src=%P project

    Not whinging at all: I’m stoked by the improvements. :-)

    I’ve just been wondering about getting project info in build line, for a multi-project setup (which is already enabled by the plugin, ofc.)

  2. Interesting. I’m using ucc (the UnrealScript compiler, which is actually run from Wine because Epic Games never bothered to port it to Linux), and the build plugin reports the build status correctly, but not line numbers (and IIRC some warning and error lines are also misidentified). So it makes me wonder if these changes will improve that. And if not, I wonder if it’s hard to add such compiler support…

  3. GreatEmerald: these won’t no, but istr something about changes in that area a few weeks ago. I guess we want a glob match, which can be specified in the syntax.xml if not default error:* or warning:*

    Thanks Alex; and format for: make katetargets?

    Yes, I push, but only on the small stuff after the event, so it’s polished and I can get straight to work with it. ;-)

  4. Build plugin works great, but is not compatible with smb. I’m editing files on smb share and compiling them over ssh (with target command like: ssh user@host “cd /media/workspace/lcd_test;make”) – building works ok, but when i click on error listed on output it cannot open the desired file with message “Could not start process Unable to create io-slave: klauncher said: Unknown protocol ”.”
    On target settings I’ve configured working directory to smb share: smb:// but it didn’t work.
    Why I think it can be useful? For example compiling projects on Raspbrry Pi.

    1. I’ve figured out that jumping to errors works when you mount your smb share into a corresponding path on your computer. This means that if you mount for example /home/user shared folder to /media/raspi – it will not work, it has to be the same path on both devices – in my case /media/workspace share is mounted in /media/workspace on my laptop.

      With all that I’m able to write and build on raspberry pi using my laptop and get the benefits of jumping to errors :)

  5. Is there a way to disable automatic switch to parsed output in case of error? I have assembler which is producing error log output in somewhat different format, and on parsed view there’s nothing displayed, so I always must click to switch back to full output.

    1. Ok, just today I did dig a bit deeper into the issue, what is actually going on, and the thing is, that the assembler is outputting the diagnostic message to “stdout”, but the Kate parser will find it only when “stderr” would be used, so while the full output will display also “stdout”, the “parsed” modes are empty…

      So it would be nice from Kate to NOT switch to parsed view when full output is non-empty, but error tree is empty (for tools like above).

      I’m not sure, if parsing also “stdout” is good idea (maybe yes, if “stderr” is empty, but it may then parse also quite bogus outputs of tools which don’t produce error/warning diagnostic at all but something completely different, yet somebody launched them through Kate).

      And I will check if I can modify the assembler to use “stderr” in future.

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top