July 25, 2017 at 14:03How I cooked CLion
The story of CLion, docker, conan, cmake, ninja, cotire and gdb.
I’ve been doing C ++ development for about 15 years and once started with Watcom C. I have fond memories of him. But, since I had to write more for the UNIX console, I switched to vim as an IDE. In general, it is quite convenient. Its plugins work wonders, you can configure autocomplete, view class hierarchies, quickly jump to definitions or search, in general, everything an IDE should be able to do can be raised there. The pain comes at a time when you are trying to install and master a new plugin. This all starts not everywhere and not always, and often eats percent and memory worse than any java.
Periodically, I glanced at Qt Creator. But he did not dare to switch to it.
And so, at one of these moments I came across CLion. After the constructor called vim, I really wanted to get the solution out of the box. At first glance, I really liked him. Quick tips, easy navigation, work with cmake projects, as with native ones, support for vim mode (though later I turned it off).
The bummer happened quite soon. The fact is that, although I am writing at the moment mainly under linux, I have macbook pro as a workstation. Yes, I am like this! And I sincerely consider perverts people who, having bought an apple laptop, install anything other than macOS on it. Therefore, the ability to remotely build or build through docker is critical to me. And it, no matter how many users have requested, is not in CLion yet. The first attempt at the transition ended in nothing - there is no “out of the box” solution.
But the pain with configuring vim didn’t go anywhere, and I decided to give CLion a second chance - to try to solve the problems that I faced before, myself. And this:
Before that, I used the libraries that come in packages together with the OS. With CLion, I would have to drop all the OS header files onto my Mac, which I absolutely did not want. But here conan helped me out. It stores all the compiled libraries in a separate directory, which you can easily attach to yourself.
With the second, everything was not so simple. I decided to just replace cmake with my script that will build inside the docker container. I did not smile every time I synchronize my code from the repository or pour it back in, add / remove an additional Target in CMakeLists.txt, as I was advised. I wanted to be able to clone any project and immediately get together without dancing with a tambourine. It was not so simple. The main difficulty was the assembly of the CLion test project, which it performs when changing the toolchain, and the forwarding of parameters containing spaces inside the container. But I did it.
It would seem - I did it!
...
I heard that building in C ++ using C ++ 14 or C ++ 17 is a rather slow thing, and, at first, I attributed everything to the compiler's slowness. But then he noticed that remotely on a dedicated server it was going to somehow somehow too smartly. The larger the project became, the greater doubts arose in my soul.
The docker ended up with a double bottom. Yes, the server rises quickly, only compilation on osxfs works, as it turned out three times slower than on overlay. Therefore, I had to switch to using rsync. Also, I discovered docker volume settings. If you use delegated, the build speed increases by 15 percent. Details .
Along the way, I measured the build time through ninja against the standard make - the difference came out almost twice. True CLion requires you to get it through make, otherwise, say goodbye to the tips. I had to run the assembly twice, once through make, for CLion, the second through ninja. The gain here is that the project changes quite rarely, and you need to get together often.
Also, I tried using precompiled headers (cotire) - the effect turned out to be ambiguous. In addition, this required the manual generation of stdafx.h (or any other file) and its inclusion in all .cpp. And this, in turn, is not very like CLion. He begins to consider all other include redundant. This could be circumvented, but the gain was not so significant.
The last thing I did was abandon ccache. In my case, it gave a delay of about a second. Yes, if a suitable file is found, this speeds up the assembly. But this does not often happen when you write new code.
Since the assembly started up, why not try to push and debug!
I used to think that gdb inside docker could not be started. It turned out that this is not so. The --security-opt seccomp: unconfined option removes this problem. And the article describes in detail how and what to configure. But, and then there was an unexpected bummer. I was going through clang (which is logical), but for debugging you need to use gcc. Otherwise, you can run the application in the debugger, but you can no longer see the values inside the stl containers. Basically, building through gcc is not a problem. Then, it really works.
Mice cried, pricked, but continued to eat a cactus ... We are waiting! We are waiting for the remote assembly. We are waiting for full support for C ++ 17. JetBrains and JFrog always mention each other in their newsletters, but there is no integration yet. Even when assembling locally, you will have to enter conan commands manually. We are waiting!
It would also be nice to get build support through ninja. 50% of productivity on the road are lying around.
Who cares, my scripts and Dockerfile for building a template can be found on GitHub .
Short introduction
I’ve been doing C ++ development for about 15 years and once started with Watcom C. I have fond memories of him. But, since I had to write more for the UNIX console, I switched to vim as an IDE. In general, it is quite convenient. Its plugins work wonders, you can configure autocomplete, view class hierarchies, quickly jump to definitions or search, in general, everything an IDE should be able to do can be raised there. The pain comes at a time when you are trying to install and master a new plugin. This all starts not everywhere and not always, and often eats percent and memory worse than any java.
Periodically, I glanced at Qt Creator. But he did not dare to switch to it.
First meeting
And so, at one of these moments I came across CLion. After the constructor called vim, I really wanted to get the solution out of the box. At first glance, I really liked him. Quick tips, easy navigation, work with cmake projects, as with native ones, support for vim mode (though later I turned it off). The bummer happened quite soon. The fact is that, although I am writing at the moment mainly under linux, I have macbook pro as a workstation. Yes, I am like this! And I sincerely consider perverts people who, having bought an apple laptop, install anything other than macOS on it. Therefore, the ability to remotely build or build through docker is critical to me. And it, no matter how many users have requested, is not in CLion yet. The first attempt at the transition ended in nothing - there is no “out of the box” solution.
Second attempt
But the pain with configuring vim didn’t go anywhere, and I decided to give CLion a second chance - to try to solve the problems that I faced before, myself. And this:
- Lack of locally installed libraries. CLion cannot give hints for classes whose descriptions it does not see
- The assembly itself
Before that, I used the libraries that come in packages together with the OS. With CLion, I would have to drop all the OS header files onto my Mac, which I absolutely did not want. But here conan helped me out. It stores all the compiled libraries in a separate directory, which you can easily attach to yourself.
With the second, everything was not so simple. I decided to just replace cmake with my script that will build inside the docker container. I did not smile every time I synchronize my code from the repository or pour it back in, add / remove an additional Target in CMakeLists.txt, as I was advised. I wanted to be able to clone any project and immediately get together without dancing with a tambourine. It was not so simple. The main difficulty was the assembly of the CLion test project, which it performs when changing the toolchain, and the forwarding of parameters containing spaces inside the container. But I did it.
If everything is fine with you, you simply don’t know everything yet.
It would seem - I did it!
...
I heard that building in C ++ using C ++ 14 or C ++ 17 is a rather slow thing, and, at first, I attributed everything to the compiler's slowness. But then he noticed that remotely on a dedicated server it was going to somehow somehow too smartly. The larger the project became, the greater doubts arose in my soul.
The docker ended up with a double bottom. Yes, the server rises quickly, only compilation on osxfs works, as it turned out three times slower than on overlay. Therefore, I had to switch to using rsync. Also, I discovered docker volume settings. If you use delegated, the build speed increases by 15 percent. Details .
Along the way, I measured the build time through ninja against the standard make - the difference came out almost twice. True CLion requires you to get it through make, otherwise, say goodbye to the tips. I had to run the assembly twice, once through make, for CLion, the second through ninja. The gain here is that the project changes quite rarely, and you need to get together often.
Also, I tried using precompiled headers (cotire) - the effect turned out to be ambiguous. In addition, this required the manual generation of stdafx.h (or any other file) and its inclusion in all .cpp. And this, in turn, is not very like CLion. He begins to consider all other include redundant. This could be circumvented, but the gain was not so significant.
The last thing I did was abandon ccache. In my case, it gave a delay of about a second. Yes, if a suitable file is found, this speeds up the assembly. But this does not often happen when you write new code.
Appetite comes with eating
Since the assembly started up, why not try to push and debug!
I used to think that gdb inside docker could not be started. It turned out that this is not so. The --security-opt seccomp: unconfined option removes this problem. And the article describes in detail how and what to configure. But, and then there was an unexpected bummer. I was going through clang (which is logical), but for debugging you need to use gcc. Otherwise, you can run the application in the debugger, but you can no longer see the values inside the stl containers. Basically, building through gcc is not a problem. Then, it really works.
Epilogue
Mice cried, pricked, but continued to eat a cactus ... We are waiting! We are waiting for the remote assembly. We are waiting for full support for C ++ 17. JetBrains and JFrog always mention each other in their newsletters, but there is no integration yet. Even when assembling locally, you will have to enter conan commands manually. We are waiting!
It would also be nice to get build support through ninja. 50% of productivity on the road are lying around.
Who cares, my scripts and Dockerfile for building a template can be found on GitHub .