Add cmake-ide to lang/c-c++ layer #7187
Conversation
cmake-ide nicely orchestrates between cmake, flycheck, company-clang and RTags by using cmake to generate a compile_commands.json that it uses to set the appropriate compile flags for flycheck and company-clang. This nicely centralizes all build related settings where they belong: in the build system itself. It comes with a zero need for configuration and usually works just out of the box. Nevertheless, and recommended as well, build directory and additional compile flags (...) can also be set through directory local variables. In the future, we could improve here on the user experience by providing an automatic and predicable naming scheme for build dirs that the user can partially influence through a base directory variable. With that in place, those build directories would be fully automatic and still reusable by cmake-ide. Since cmake-ide makes it a breeze to use RTags by automating much of the necessary setup, I see this as a precursor to proper RTags support which also requires the rtags lisp package to be installed and required along with the RTags client/server counterpart (see pull request #2834).
|
Meanwhile my PR got merged upstream (atilaneves/cmake-ide@3e20bd7) and we thus have the concept of build pool directories and persistent naming of automatic build directories. That makes cmake-mode even more useful since one can pretty much use it without having to configure it per project, if one wants. If there is anything that needs improving or that is holding this back from being merged, please let me know how I can help out. Thanks a lot. |
|
+1 this would be great to have |
|
Are the original comments made by TheBB still an issue? Since the package still provides useful features even without using other packages. |
|
I will have a look at the C/C++ layer soon™, including this and the rtags PR. |
|
Any one have a private layer with this? |
|
This would be really nice to have |
|
@BinaryKhaos please rebase your pull request on the current development branch. Ask for help if you need any. |
|
@beta1440 , I did new PR #9418 - it contains the same changes, rebased on current master branch |
|
@myrgy -- your PR should not be made against |
|
@robbyoconnor , does PR to develop will b enough? Or you noticed some other issues with that PR? |
|
Yes. If there's one against develop already, then closing this is the
right idea -- but that one has conflicts -- so maybe rebasing against
develop might be the solution.
|
|
@robbyoconnor , done. plz see #9432 |
|
this PR could be close because #9432 has been merged |
|
@BinaryKhaos Thank you! 💜 My sincere apologies, this PR has not been merged in due time and has been replaced by a more recent PR. I hope it won't prevent you from opening new PRs, don't hesitate to ping me with a PM on gitter if you have stalled PRs that you judge important and useful. |
cmake-ide nicely orchestrates between cmake, flycheck, company-clang and RTags by using cmake to generate a compile_commands.json that it uses to set the appropriate compile flags for flycheck and company-clang. This nicely centralizes all build related settings where they belong: in the build system itself.
It comes with a zero need for configuration and usually works just out of the box. Nevertheless, and recommended as well, build directory and additional compile flags (...) can also be set through directory local variables. In the future, we could improve here on the user experience by providing an automatic and predicable naming scheme for build dirs that the user can partially influence through a base directory variable. With that in place, those build directories would be fully automatic and
still reusable by cmake-ide.
Since cmake-ide makes it a breeze to use RTags by automating much of the necessary setup, I see this as a precursor to proper RTags support which also requires the rtags lisp package to be installed and required along with the RTags client/server counterpart (see pull request #2834).