CLion custom compiler support plugin/wrapper

Answered

I'm trying to implement support of several embedded compilers (e.g. Microchip's xc8) to be used with CLion seamlessly. And rough implementation is not what I want to get, because I have already made a gdb stub for small devices which works as a gdbserver and now want to fully integrate toolchain with CLion.

First appoach was to implement a wrapper and mimic to gcc/clang. Now I have all the input params and output std streams from CLion's gcc calls and did some work to make an own wrapper, but without knowledge of what CLion tries to parse out of every command it is very unproductive way to go.

Now I wonder if this task can be implemented via plugin patching some hard-coded gcc related functions?

7 comments
Comment actions Permalink
Official comment

Andrey Myasoedov, we have analyzed those opportunities, but found that uncommon compilers are very different to obtain the  required information. Any of those semi-automatic data extractors are going to be either too complicated, or not enough flexible, or both.

I think in your case it's easier to write a script which runs your particular compiler with certain keys, process the output and then writes the .yaml file. I am going to make an example for SDCC when I have time.

And yes, when you've done with your cx8, please share your work to the community by submitting a pull-request to https://github.com/JetBrains/clion-custom-defined-compiler-examples/tree/master/configs

Comment actions Permalink

Hi Andrey!

We've just released an ability to use a custom compiler in CLion - https://blog.jetbrains.com/clion/2021/10/clion-2021-3-eap-custom-compiler/#using_a_custom_compiler_in_clion.

Feel free to give it a try! And please share your feedback with us.

0
Comment actions Permalink

Wow! Perfect just-in-time answer )

I've tried the proposed method and it is good enough in except that passing defines as static 'name: value' or defines-text is not always a good idea. I'ts much better to have the optional ability to query the compiler for that values using command-line flags (like gcc -v -E -dD), as some defines can be changed due, for example, to crystal swap or debugger change and always should be maintained via this yaml manually.

Just think of alternative notation to all the fields including even compiler name to execute external program and grab the output like:

description: `gcc --version|grep gcc`
0
Comment actions Permalink

Ilia Motornyi, thanks for the answer.

I've managed all the things with the custom compiler under CLion, but it turned out to be a little bit widescale than expected. No static Yaml-files was made as the result.

I had to dig inside CMake itself and make an extension to the CMake system (although running in the project's scope without any system changes) which eliminates need for proiper detection and configuration of a compiler by the CMake and avoids misbehaving of the Generic in the CMake. And as a bonus also produces CLion yaml files for the custom compiler.

This framework with a litle description is available here https://github.com/ma5ter/Platform

1
Comment actions Permalink

OMG. Great work!
Don't you want submit your xcx8 support to CMake itself?
https://gitlab.kitware.com/cmake/cmake/blob/master/CONTRIBUTING.rst

0
Comment actions Permalink

It's just a first workaround of the big problem, may be little bit later I'll make a proper commit to the CMake, not now )

Now I'm focused on getting debugger on 8-bit PIC controllers to work with CLion via custom gdbstub, so it's near possible that I'll ask some stupid questions about the CLion and debugging mechanics soon.

1
Comment actions Permalink

Sounds great, you are welcome.

0

Please sign in to leave a comment.