Clion and vala: what would it take to support a new language?

I have never developed a plugin/module for the jetbrains and I wonder how hard would it be to support a new language.

And by new language, I mean vala.
Vala is a modern language (think C#) that simply compile to C files (that are compiled with gcc/clang).
(Here's a tutorial for the curious)
It has bindings to many many native library, provides deep integration with Gnome.
Basically, it's the secret weapon behind elementaryos (all the desktop applications - windows manager, music player, file explorer ... -  are developped in vala)
(Don't be fooled by the ugly wbebsite, the language is awesome, and the guys behind it great all around)

But enough of the sales pitch :)

While vala is very nice, the tooling around it is lacking.
Granted cmake has built-in support, but gdb is still the debugger of choice (aouch).

My goal would be to leverage the awesome clion existing features to support vala cmake and use the clion integrated debugger (while tailoring it a little).
Only that: the other stuff like formatting, refactoring, even coloring can wait.

So I have the following questions:

  1. How hard would it be for an experienced vala/java developer? (a matter of days/weeks/months?)
  2. Can the existing C debugger be leveraged for projects that doesn't work on C files (but generate C files - and compile files with the #line directive)
  3. Can the existing debugging be extended (vala classes are mapped to C structs. So a mapping is needed to show the variables values in the debugger)
  4. What would likely be the next steps?


Any feedback is welcome.

Carl.

5 comments
Comment actions Permalink

Hi Carl,

CLion uses GDB but currently we don't have an open API for it that would allow create extensions. We do, however, plan to support user-defined renderers, so that would allow you to handle dispaly of custom structs.

The same goes for CMake support: at the moment there is no API, but I'm not sure what kind of special support Vala would require on this side.

In any case, implementing proper support of what you've described will probably take months.

0
Comment actions Permalink

Thanks for your answer.

So if I understand well, while the intellij platform is extensible, clion is not.
So it means that if I need to extend some clion features, I would need to re-implement them.

For example, if I would need to use vala external bindings (think C# dlls that would be available via the debian repository and accessed via pkgconfig) in the build system, I would need to re-implement the whole cmake management *and* add the vala bindings management on the top of it.
Is that correct?

Another example: on a debug breakpoint, the debugger would need to list object properties and members.
But that can't be done on C level (as the variables name is mangled and the properties are functions).
So a vala specific layer is needed there.
If I understand you correctly, there is no way to leverage the existing the gdb infrastructure.
I would have to reimplement all of it *and* add my vala layer on the top of it.

Is that correct?
Carl.

0
Comment actions Permalink

Again, if there already exists support Vala support for CMake, then there is probably no need to implement anything else.

Regarding debugger: sounds about right, current state of things does not allow you to reuse an existing functionality.

0
Comment actions Permalink


Again, if there already exists support Vala support for CMake, then there is probably no need to implement anything else.


Well I guess some customization would be needed to register a new file type (*.vala) and provide templates for empty files.

Thanks for your answar anyway.

Carl.

0
Comment actions Permalink

Carl,

While supporting new languages is definitelly out of scope of CLion road map, you can try a small DIY project.
If you are interested, you can read about developing a custom languate plugin for IntelliJ Platform (which CLion is based on).

0

Please sign in to leave a comment.