How I cooked CLion
The story about CLion, docker, conan, cmake, ninja, cotire and gdb.
I have been developing in C ++ for 15 years and once started with “Watcom C”. About him I have the warmest memories. 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 do wonders, you can set up autocomplete, view class hierarchy, quickly go to the definition or search, in general, everything that IDE should be able to do there can be raised. The pain comes at the moment when you are trying to install and master the new plugin. It all starts up not everywhere and not always, and, often, it eats percent and memory worse than any java.
Periodically, I looked at Qt Creator. But he did not dare to go on it.
')
And so, at one of those moments, CLion caught my eye. After the designer 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 family, support for vim mode (although, later, I turned it off).
Bummer happened pretty soon. The fact is that although I am writing at the moment mainly under linux, I have a macbook pro as a workstation. Yes, I am like this! And I sincerely consider perverts of people who, having bought an apple laptop, install something other than macOS on it. Therefore, the possibility of a remote build or build via docker is crucial for me. And her, no matter how many users have asked, is not in CLion yet. The first attempt at transition ended in nothing — there is no solution out of the box.
But the pain with the vim setting did not go anywhere, and I decided to give the CLion a second chance - to try to solve the problems that arose before me on my own. And this:
Before that, I used libraries that come in packages with the OS. With CLion, I would have to throw all the OS header files on my Mac, which I absolutely did not want. But here I was rescued by conan. It stores all the collected libraries in a separate directory that you can easily put on 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 didn’t smile every time I synchronize my code from the repository or add it back, add / remove an additional Target in CMakeLists.txt, as advised me. I wanted to be able to clone any project and immediately get together without dancing with a tambourine. It was not so easy. The main difficulty was caused by the assembly of the test project CLion, which it performs when changing the toolchain, and the forwarding of parameters containing spaces inside the container. But I managed.
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 blamed everything on the compiler's slowness. But then I noticed that remotely on a dedicated server, it’s somehow really going too fast. The more the project became - the greater doubts were born in my soul.
Docker turned out to be a double bottom. Yes, the server rises quickly, only the compilation on osxfs works, as it turned out three times slower than on overlay. So I had to switch to using rsync. I also discovered docker volume configuration. If you use delegated - the assembly speed increases by 15 percent. More .
Along the way, I measured the build time in ninja against the standard make - the difference was almost doubled. True, CLion needs to be built using make, otherwise, forgive prompts. I had to run the assembly twice, once through make, for CLion, the second through ninja. The win here is that the project changes quite rarely, and it’s necessary to get together often.
Also, I tried to use precompiled headers (cotire) - the effect was ambiguous. In addition, it required to manually form stdafx.h (or any other file) and include it in all .cpp. And this, in turn, does not really like CLion. He begins to consider everything else to include as superfluous. This could be bypassed, but the gain was not so significant.
The last thing I did was give up on ccache. In my case, he gave a delay of about a second. Yes, if a matching file is found, it speeds up the build. But this does not often happen when you write a new code.
Since I started the build, why not try to push and debug!
I used to think that gdb inside docker could not be started. It turned out that it is not. The option --security-opt seccomp: unconfined removes this problem. And the article describes in detail how and what should be configured. But, and there happened an unexpected bummer. I was going through clang (which is logical), and for debugging I need to use gcc. Otherwise, you can run the application in the debugger, but you can’t see the values ​​inside the stl containers anymore. In principle, compiling via gcc is not a problem. Then it really works.
Mice cried, pricked, but continued to eat cactus ... We are waiting! We are waiting for the remote assembly. We are waiting for full support for C ++ 17. JetBrains and JFrog in their mailings constantly commemorate each other, but there is no integration yet. Even when going locally, you will have to enter the conan commands manually. We are waiting!
It would also be nice to get support for the assembly through ninja. 50% of the performance on the road roll.
Who cares, my scripts and the Dockerfile to build the template can be found on GitHub .
Small preface
I have been developing in C ++ for 15 years and once started with “Watcom C”. About him I have the warmest memories. 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 do wonders, you can set up autocomplete, view class hierarchy, quickly go to the definition or search, in general, everything that IDE should be able to do there can be raised. The pain comes at the moment when you are trying to install and master the new plugin. It all starts up not everywhere and not always, and, often, it eats percent and memory worse than any java.
Periodically, I looked at Qt Creator. But he did not dare to go on it.
')
First meeting
And so, at one of those moments, CLion caught my eye. After the designer 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 family, support for vim mode (although, later, I turned it off).Bummer happened pretty soon. The fact is that although I am writing at the moment mainly under linux, I have a macbook pro as a workstation. Yes, I am like this! And I sincerely consider perverts of people who, having bought an apple laptop, install something other than macOS on it. Therefore, the possibility of a remote build or build via docker is crucial for me. And her, no matter how many users have asked, is not in CLion yet. The first attempt at transition ended in nothing — there is no solution out of the box.
Second try
But the pain with the vim setting did not go anywhere, and I decided to give the CLion a second chance - to try to solve the problems that arose before me on my own. And this:
- Lack of locally installed libraries. CLion cannot give hints for classes whose descriptions cannot see.
- Actually the assembly itself
Before that, I used libraries that come in packages with the OS. With CLion, I would have to throw all the OS header files on my Mac, which I absolutely did not want. But here I was rescued by conan. It stores all the collected libraries in a separate directory that you can easily put on 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 didn’t smile every time I synchronize my code from the repository or add it back, add / remove an additional Target in CMakeLists.txt, as advised me. I wanted to be able to clone any project and immediately get together without dancing with a tambourine. It was not so easy. The main difficulty was caused by the assembly of the test project CLion, which it performs when changing the toolchain, and the forwarding of parameters containing spaces inside the container. But I managed.
If everything is good, you just 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 blamed everything on the compiler's slowness. But then I noticed that remotely on a dedicated server, it’s somehow really going too fast. The more the project became - the greater doubts were born in my soul.
Docker turned out to be a double bottom. Yes, the server rises quickly, only the compilation on osxfs works, as it turned out three times slower than on overlay. So I had to switch to using rsync. I also discovered docker volume configuration. If you use delegated - the assembly speed increases by 15 percent. More .
Along the way, I measured the build time in ninja against the standard make - the difference was almost doubled. True, CLion needs to be built using make, otherwise, forgive prompts. I had to run the assembly twice, once through make, for CLion, the second through ninja. The win here is that the project changes quite rarely, and it’s necessary to get together often.
Also, I tried to use precompiled headers (cotire) - the effect was ambiguous. In addition, it required to manually form stdafx.h (or any other file) and include it in all .cpp. And this, in turn, does not really like CLion. He begins to consider everything else to include as superfluous. This could be bypassed, but the gain was not so significant.
The last thing I did was give up on ccache. In my case, he gave a delay of about a second. Yes, if a matching file is found, it speeds up the build. But this does not often happen when you write a new code.
Appetite comes with eating
Since I started the build, why not try to push and debug!
I used to think that gdb inside docker could not be started. It turned out that it is not. The option --security-opt seccomp: unconfined removes this problem. And the article describes in detail how and what should be configured. But, and there happened an unexpected bummer. I was going through clang (which is logical), and for debugging I need to use gcc. Otherwise, you can run the application in the debugger, but you can’t see the values ​​inside the stl containers anymore. In principle, compiling via gcc is not a problem. Then it really works.
Epilogue
Mice cried, pricked, but continued to eat cactus ... We are waiting! We are waiting for the remote assembly. We are waiting for full support for C ++ 17. JetBrains and JFrog in their mailings constantly commemorate each other, but there is no integration yet. Even when going locally, you will have to enter the conan commands manually. We are waiting!
It would also be nice to get support for the assembly through ninja. 50% of the performance on the road roll.
Who cares, my scripts and the Dockerfile to build the template can be found on GitHub .
Source: https://habr.com/ru/post/334080/
All Articles