
Using Vim for C++ Development - ingve
https://gist.github.com/p1v0t/42a34744b5e4f5980e5f4e1c980ec859
======
W0lf
Before switching to CLion eventually, I've used my well curated VIM config[1]
together with YouCompleteMe and several clang-based tools such as clang-
format, clang-rename etc. for several years, working on smaller and large
C/C++ codebases with reasonable success.

At some point in time I switched to a full-fledged IDE (CLion) because there
are certain refactoring tasks which are probably still possible using this
setup but I found them to be mentally too complex to deal with, especially
when I am focusing on the task at hand at the same time.

[1] [https://github.com/NewProggie/Dev-
Utils/blob/master/dotfiles...](https://github.com/NewProggie/Dev-
Utils/blob/master/dotfiles/.vimrc)

~~~
alfalfasprout
+1 to CLion. Vim is great for what it is-- if I need to make a small edit or
even work on C code it does the job well and is very fast and efficient. But
at the end of the day it's not a full blown IDE and as such is missing a
graphical debugger and profiler, good configuration for interactively running
unit tests, and complex refactoring tools.

CLion is pretty much the best C++ IDE I've found by a mile. Eclipse is so slow
and terrible I won't even consider it. Visual Studio is amazing but Windows
only and _really_ heavyweight. VSCode, Atom, etc. aren't really "proper" IDEs.
Then there's open source contenders like Jucipp which while very fast do lack
a lot of the niceties of their paid competitors.

My only gripe with CLion is that it's CMake only. This limits its usefulness
for Bazel or Autotools projects.

~~~
mrich
What are you missing in VSCode to make it a proper IDE?

~~~
CalChris
VSCode gets the look right. Indeed, its look is fantastic. But it doesn't get
the feel of vim right at all. My fingers speak vim and they know whether
they're talking to vim or something hinky. So after a few days with VSC, I go
back. Usually it has to do with ex mode which I power edit in a lot. But I do
look at VSC every year or so and it gets better.

------
fredsanford
Yeah, lets take lightweight vim and add a node.js runtime and make a better
ide.... _sigh_

At that point you might as well use QT Creator.

~~~
vyskocilm
I personally prefer [https://github.com/dense-
analysis/ale](https://github.com/dense-analysis/ale) plugin. It is in
vimscript and supports almost everything (including clangd) out there:
[https://github.com/dense-
analysis/ale/blob/master/supported-...](https://github.com/dense-
analysis/ale/blob/master/supported-tools.md)

~~~
gen220
Is there some feature that coc.vim has that ale does not? Can someone explain
coc.vim's popularity to me?

I don't understand why coc.vim is so popular, when Ale is so performant and
"debuggable" (i.e. produces useful performance traces).

[long-time ale user here, I don't use clangd but I do use python-language-
server, which is similar]

~~~
jswny
Generally it's because Coc has completion, snippets, and pretty much
everything from the regular VSCode version of the extension built-in, so Coc
can replace multiple plugins, and it works very well.

~~~
gen220
Right, but Ale does this too (replace multiple plugins, supports completion,
linting/formatting).

Is it that coc.vim doesn't make you install the binaries of the tools (i.e.
go-pls, python-language-server, clangd)? If so, that would be enough to
explain the popularity to me.

IMO, one could make the argument that it's somewhat antithetical to vim-
culture, to not understand the non-vim binaries your editor is executing.

~~~
nikki93
One thing I really like in coc is I can ask to describe a symbol and it'll
tell me about it in a hover thing:
[https://i.imgur.com/NrH0Wwz.png](https://i.imgur.com/NrH0Wwz.png)

Do agree that coc is probably the least 'vim-culture'-ey part of such a setup,
but hey it does good things. :) I don't think you need to justify using Ale so
hard and put coc down, could just use whichever you prefer personally.

~~~
gen220
Sorry if I came across that way. Agree people should use the things they
prefer. :)

I'm trying to see if I'm missing something big/obvious, since coc.vim has been
so popular recently.

~~~
nikki93
No worries! And yeah I went through a phase a few months ago of trying out the
completion packages again, it's worth just trying and seeing if you like it.
Here's the relevant bits of my config if that helps:
[https://gist.github.com/nikki93/6ea403d3e2cbff2b3d32d4528edf...](https://gist.github.com/nikki93/6ea403d3e2cbff2b3d32d4528edf5ee5)

coc.nvim has pretty much worked pretty well out of the box for many languages,
and it works for me on macOS, Linux and Windows.

------
ainar-g
You don't actually need NPM and CoC. I've been using pure-VimL vim-lsc[1] for
a couple of years, and it's been serving me well. My config:

    
    
      let g:lsc_auto_map = {'Completion': 'omnifunc'}
      let g:lsc_enable_autocomplete = v:false
      let g:lsc_server_commands = {
      \  'c': {
      \    'command': 'clangd',
      \    'log_level': -1,
      \    'suppress_stderr': v:true,
      \  },
      \  'cpp': {
      \    'command': 'clangd',
      \    'log_level': -1,
      \    'suppress_stderr': v:true,
      \  },
      \}
    

This gives me code completion and other niceness.

With Vim 8.1, you don't even need a package manager, since there is one built
in. Just clone the Git repo into your ~/.vim/pack/vim-lsc/start/vim-lsc/.

[1] [https://github.com/natebosch/vim-lsc](https://github.com/natebosch/vim-
lsc)

------
benreesman
+1 for clangd (not to mention clang-tidy and clang-format). On Ubuntu 20.04
clang-10 is is in the standard repositories (I’ve heard it’s well-supported on
other distributions), and the setup is seamless.

clangd eats big-ass, hairy, template-heavy TUs for breakfast as concerns
responsiveness, and I have yet to see it make a mistaken autocomplete
suggestion or fail to find a declaration that I agreed with. It’s easily the
equal in precision of the Intellisense server that some of my colleagues use
and doesn’t bog down the same way. Even the method renaming is pretty solid.

For me at least it’s a small but consistent productivity increase over any of
the alternatives I’m aware of and fits into your existing emacs/vim/vscode
workflow.

Would download for free again.

~~~
babuskov
> It’s easily the equal in precision of the Intellisense server that some of
> my colleagues use and doesn’t bog down the same way. Even the method
> renaming is pretty solid.

> For me at least it’s a small but consistent productivity increase over any
> of the alternatives I’m aware of

Have you tried Eclipse CDT?

Since nobody mentions it, I guess I have to. It takes some time to set it up
(system paths, etc.) but once you do, it makes browsing and refactoring code a
breeze.

It works much faster than Intellisense and stuff like dependency trees (call
hierarchy, etc.) are much easier to navigate.

I'm using it as my main editor since 2014 or so. Have tried various
alternatives on all 3 platforms (Linux, macOS, Windows), but I always go back
to it for C++ dev.

~~~
cardiffspaceman
I was using CDT until WFH started in March. At the time Remote System Explorer
appeared to be dead-ish so I went with VSCode. Eclipse CDT is extremely
tedious to configure the include paths for because they all have to be entered
one by one in a text box. VSCode has a remote system extension and include
paths can be entered en masse into a JSON file. I've used both with embedded
projects that involve cross compilers. VSCode doesn't know MIPS processors are
a thing so some of my linux driver code has unwarranted squiggles. For Eclipse
the same constructs are handled by the methods it uses for any code. Eclipse
supports its superior features with a lot of reindexing. VSCode supports its
features with glorified searches.

------
lionkor
I can thoroughly recommend vim for C++ development that doesn't stretch over
too many files and directories. Especially with custom include paths and a
constantly changing bigger project, vim becomes almost unusable for me.

I can very much recommend QtCreator. I don't use Qt, but as an IDE it's very
well made. The fact that it can also do Qt isn't even apparent when you use it
on normal CMake projects and the like.

Extremely solid syntax highlighting is also important to me, which, in vim, is
horribly difficult if not impossible. If I want something nested like
`std::this_thread::get_id` to be highlighted properly, want macros to be a
different color, want local scope variables to be a different style than
class-scope or globals, vim is out of the question.

So yes, I can recomment vim for C++ development as long as you're not using a
ton of libraries and are okay with most of your code being the exact same
color.

~~~
spacechild1
I can also recommend QtCreator for C++ development! I regularly use it for my
cross-platform open source projects (none of them are Qt based) and it works
equally well on Windows, macOS and Linux.

~~~
HeckFeck
Andreas Kling has used it to develop an entire operating system (Kernel to
DE), so it can't be that bad.

------
kovac
Well, let me tell you how to do c++ programming with Vim. Get a Linux machine,
replace the desktop with i3wm. Get a terminal emulator like urxvt and make it
dark and semi transparent. Set a beautiful wallpaper. Install YouCompleteMe.
Now you are in paradise :)

~~~
jvanderbot
God how i3wm changed my life for the much, much better.

~~~
hyperpl
This may be considered blasphemy, but I continue to use i3-gaps on my 43" 4K
monitor in 100% floating mode. It actually works quite well. Of course for my
small displays I use tiling mode.

~~~
approxim8ion
Imo if you're only floating, Openbox is even lighter than i3 and works great.
Super configurable too- the config file is just XML. I really enjoyed my time
on it but I like tiling too much. Window-snapping wasn't enough.

~~~
boring_twenties
Ick.

I use xmonad, despite not knowing any Haskell. I basically just copy pasted
little snippets from all over the place and changed random characters until it
started working.

Pretty sure I still prefer this state of affairs to XML.

------
Jeaye
Semantic highlighting for C++ can be achieved in Vim using color_coded:
[https://github.com/jeaye/color_coded](https://github.com/jeaye/color_coded)

It can make a huge difference in the highlighting of the source, compared to
Vim's regex-based approach. The reasoning for wanting this is to be able to
soak in more information about the source without needing more text; the color
alone can convey a lot of useful info about the code.

~~~
gkfasdfasdf
Agreed about the usefulness of semantic highlighting. Also,
[https://github.com/jackguo380/vim-lsp-cxx-
highlight](https://github.com/jackguo380/vim-lsp-cxx-highlight) works really
well with CoC and LanguageClient-neovim, and doesn't need to be compiled.

------
hknapp
For C, default vim comes with:

    
    
      (somewhat) intelligent complete (ccomplete)
    
      debugging (termdebug)
    
      jump to definition (ctags)
    
      reference finding (cscope)
    
      file explorer (netrw)

~~~
Asooka
Oh yeah, for plain C, Vim is absolutely good enough. Virtual methods and
templates drive the complexity of intellisense and refactoring up to 11. The
absolute worst is when you're trying to call a method on a function argument
of a templated type. The completer basically has to analyse every single
callsite and present you with the intersection of all types that might be
used.

------
fsloth
My alternative is to use the IDE with Vim keyboard bindings. Much nicer, full
tooling support etc. I love vim keybindings but am fully ambivalent about
everything else...

~~~
nonbirithm
As it stands Evil is the only Vim keybindings add-on that actually feels like
using Vim. Everything else will inevitably be missing a feature or not act in
exactly the way you expect, leading to disappointment. That and you also lose
out on Vim extensions.

~~~
modernerd
Evil is very good, but moving to Emacs from vim was not quite the smooth ‘just
use evil and you get the best of vim with the power of Emacs’ experience that
people say, at least for me.

I found it needed some extra configuration before it felt like stock vim.

C-u isn’t bound to "scroll up" by default with evil, for example. You have to
(setq evil-want-C-u-scroll t). That took a while to figure out and I expected
it to work that way by default.

Then you have to (setq evil-want-keybinding nil) and install evil-collection
and evil-magit to be able to use vim movements in other Emacs buffers.

Or you have to learn Emacs shortcuts and just use vim for editing, but that
feels awkward for a vim native.

As an Emacs newbie I still find it unsettling that documentation for packages
and for Emacs itself all uses Emacs-style shortcuts. Of course it couldn’t
really be another way, but I either have to learn those or remap things to
vim-style leader bindings. It makes vim usage in Emacs feel a little uncanny
at times.

I could use a distro like Doom which has it all wired up for vimheads already,
but then I’m learning someone else’s shortcuts and system, which takes away
from the point of Emacs a little for me (the idea that you make it your
editor).

Maybe it gets easier with time. If any other vim users made the move to Emacs
I’d love to hear some tips!

~~~
nonbirithm
My advice at this point is something along the lines of "use Doom," because
all that time you would normally put into wrangling evil into doing what you
want it to would instead be offloaded onto another person who makes wrangling
Emacs in general his hobby.

It's like the small things such as binding C-u to scroll up by default are
taken care of for you out of the box. How many people who use Evil who are
already familiar with Vim are going to _not_ end up setting that configuration
option in plain Emacs at some point? (Maybe those who use page up and page
down, but not even those commands do the same thing as C-u and C-d, at least
in Evil.) Everyone else will have to add that line to their config, and that
quickly gets unmaintainable if what you actually want to do is focus on work
instead of building a proper Emacs framework. So it is set for you already.

Doom is basically that for Evil configuration and several thousand other
things.

One downside is having to undo some of Doom's built-in things if they're
annoying. One example of this is having to insist that it uses a specific set
of completion handlers and not globally set a hardcoded list for every mode.
Still, the amount of time you'd have to do this is less than the amount of
time it takes to build 30% of Doom for just the features you want from
scratch.

And yes, it is at times a sad feeling needing to fall back on someone else to
do the hard work for you, but the realities of work and limited free time
essentially dictated that decision for me.

~~~
modernerd
Thank you, that's helpful, and I recognise a lot of the pain points and pluses
there.

I started with Doom, loved it, but wanted to understand Emacs better so ended
up writing my own config.

I now understand Emacs a _little_ more, I know what every line of my config is
doing, and there isn't an extra layer of abstraction or opaque bash commands I
have to periodically run. I also feel more comfortable that Emacs with a home-
grown config will last me 10+ years. It's incredible what Henrik has achieved
and the level of dedication and support is astounding, but I wonder how
sustainable it is as the community inevitably grows.

Rolling my own setup has certainly made me appreciate Doom a whole lot more,
though. And it's hard to shake the feeling that I could spend a year or two
just hacking on Emacs to get half of what Doom offers.

It's like the trap of wanting to get into game programming and finding
yourself writing a game engine instead of a game. (I picked up Emacs to learn
Clojure and other Lisp dialects better.)

It's also a little silly to have an expectation that I need to understand
everything that Doom does behind the scenes. I don't have that expectation
with Emacs itself, or with IntelliJ or vim, or VS Code…

Maybe the answer is to just read the (smallish) Doom codebase to understand it
better and contribute however I can, be it in Discord, with cash, or PRs. And
get back to hacking instead of hacking Emacs…

------
choeger
Stupid question: who controls the language server? If I have multiple projects
or multiple branches of one project or even just multiple build folders for
different configurations, how do I tell the language server what I am
currently working on?

If I put the setup in my home directory, I am limited to a single setup
(compiler, stdlib).

If I put it into the project directory, I am limited to a single build for,
and potentially a single branch, and I will have multiple instances of the lsp
running if I stop working on one project.

If I put it into the build for, which seems sensible, how does the editor
decide which server to run or ask?

It seems to me that I _need_ some sort of project manager that acts like a lap
proxy and then resolves these issues. Do I need to write one myself?

~~~
Asooka
What I do currently is run an LS per repo with its configuration stored in the
repo, so:

    
    
      + ~/repos/repoA
      | - CMakeLists.txt
      | - compile_commands.json -> ../../build/repoA_config1/compile_commands.json
      |
      + ~/build/repoA_config1
      | - CMakeCache.txt
      | - build.ninja
      | - compile_commands.json
      |
      + ~/build/repoA_config2
      | - CMakeCache.txt
      | - build.ninja
      | - compile_commands.json
    

etc. for repoB, C, ...

That said I'm thinking on flipping it around - keep the LS configuration in
the build folder, and symlink the source folder in it. That way I can have
several different configurations in effect at once and switch between them
easily. Currently I have to change where compile_commands.json points to if I
want to change YouCompleteMe's completions.

Your editor should manage the language server and you should just have to
provide the configuration it expects in the directory you start it in.

------
ausjke
I use a similar approach and setting for c++, I purchased clion for two years
and rarely used it, vim is just handy and light-weight, I will probably use
clion when my project becomes huge, until then, vim is absolutely enough.

vim nowadays can find all the headers, do linter and auto-fix and auto
completion, and when you're coding, you rarely need move the mouse at all, vim
8.2+ is itself a modern IDE inside a terminal, again, light and fast, I enjoy
it.

------
ravenide
I tried this. It is basically a slightly improved VSCode at this point.

Basically, most the slowness/bulkiness of IDEs does not come from the text
editing portion.

------
fit2rule
What I really love about vim lately: Termdebug.

Its such a joy to have cscope bindings and gdb-based debugging direction
within vim itself.

This has been a joy to re-discover after forgetting that vim has a great
integrated debugger now. I keep forgetting it, but man has it been great to
use lately.

------
necrotic_comp
What's the advantage of using a LSP over, say, ctags and cscope ?

I currently am using that, along with the
[https://github.com/stefandtw/quickfix-
reflector.vim](https://github.com/stefandtw/quickfix-reflector.vim) for quick
refactors, and it seems to work fairly well.

Is it because of method signatures or is there a killer feature that I'm
unaware of ?

~~~
slezyr
cscope looks like dead project with no support of the recent versions of
C++(14/17/20)

------
hibbelig
I wish I could find (or create) a working LSP setup for the Java code base at
work. It consists of multiple projects, tied together by a Gradle build
script. IntelliJ just groks the build.gradle and Eclipse can also import it.

Is there an LSP server that can do something similar?

~~~
nonbirithm
At one point I tried embedding a language server in a running IntelliJ
process. It kind of worked, but a few problems led to me getting tired of
maintaining it:

\- Constant API updates to IntelliJ internals requiring updates to the
extension.

\- The need to run a full copy of IntelliJ in the background, and breakage in
the copy leading to requiring a full restart.

\- A lot of concurrency problems I didn't understand because by necessity it
required going deep into IntelliJ's codebase.

\- I was no longer using Java in my work environment or for personal projects,
so I had no need to use IntelliJ.

But despite this, the repo stands as the most-starred one I have. People are
still starring it even though I haven't made changes in over a year and a
half!

[https://github.com/Ruin0x11/intellij-lsp-
server](https://github.com/Ruin0x11/intellij-lsp-server)

So it sounds like this is a thing people would use, if someone wants to take
up the maintenance burden.

~~~
Asooka
IIRC, Vim has some kind of builtin support for Eclipse for Java development,
have you tried that? I admit I haven't really looked into it, just seen it
mentioned while reading the manual.

------
commotionfever
With neovim 0.5, you can drop two dependencies,

Plug -> built-in vim packages CoC -> built-in LSP client

~~~
alfalfasprout
Do you get semantic highlighting though? That was one of the big reasons just
using an LSP client wasn't enough.

~~~
commotionfever
For that I just installed vim-polyglot. Its a big ole collection of syntax and
indent rules

------
tesmar2
Has anyone used VsCode for C++/CMake development? What was your experience?

~~~
tinfoilboy
Works pretty well with the C++ extension and the cmake-tools extension. Though
at some point I ended up just swapping to invoking CMake from the command
line.

~~~
tesmar2
I haven’t found a good CMake linter, do you use one?

------
gkfasdfasdf
I really like using TabNine for completion which does a sort of AI-
autocomplete - the suggestions are usually more than just the next token, and
sometimes are scarily good.

------
Asooka
My first advice for anyone who wants to use Vim for C++ development would be -
don't. I've used exclusively Vim for over 10 years and it's too comfortable to
switch to anything else, so I'm losing out on a lot of productivity, or at
least that's what my colleagues, who have never used Vim, claim.

Pithy claims aside, it has been an interesting journey actually using Vim for
producing C++ code for large projects. There's a strong DIY element and you
end up with a setup that's much more customised than a vanilla IDE - on the
one hand giving you a certain degree of comfort in your work, but on the other
a lot of what you do is unportable to other people. The language server
protocol has been a pretty good development, I'm keeping an eye on what comes
out of those efforts, though I'm not using one personally right now.

My current setup consists mainly of exuberant-ctags for static indexing,
YouCompleteMe for intellisense and simple navigation, rtags for rich search
and light refactoring and fzf for searching. As to why I ended up settling on
these plugins:

\- ctags:

Absolutely essential. Yes, a full semantic index straight from the compiler is
better, but ctags is more than good enough for just telling you "where is this
defined". When paired with fzf, you can type part of the tag, space, part of
the directory and you'll get all tags in that directory. That's due to fzf
doing super simple substring matching in the TAGS file's lines based on your
query, there's nothing smart going on here. This tool is also very good when
you are developing multiplatform software, because the compiler cannot see all
places where a function or class is defined, since you have one definition per
platform. Technically being able to query a plethora of language servers, one
for each configuration, would be ideal, but we're not there yet, and such a
setup sounds way too fragile for my taste.

\- YouCompleteMe:

Aside from C++, it provides amazing completion support for many other
languages. It can even deal with java project files, if the readme is to be
believed. Other than for C++, I mainly use it for python. It's also good in
plaintext files for completing words and file paths. I really love its
substring matcher, just type gTFBT to get "getTheFooBarThing". Downsides: 1.
if your build system cannot produce a compile_commands.json file, you will
need to write some python code to specify compilation flags; 2. compiles each
file individually, so if some of your headers aren't freestanding, you'll get
spurious errors when editing them.

\- rtags:

Basically a language server from before the LSP protocol existed. Mainly
developed for Emacs, but the Vim integration is good enough. Continuously
indexes your source based on a compile_commands.json file. It can show you who
calls a function or uses a variable, class hierarchies, virtual method
overloads and more. I've seen it get confused if you jump branches and require
you to delete and recreate the index, but I haven't experienced that lately.

Apart from those I use a bunch of standard productivity plugins like
unimpaired, surround, nerdtree, etc. etc. Vim 8's gdb integration has been
very welcome, too. I struggled to find a good interface to gdb previously, as
everything seems to want to be Visual Studio and give you a restricted clicky
interface, whereas I just wanted the current vim buffer to be synchronised
with the instruction pointer and to write gdb commands directly.

I don't feel like I'm substantially slower in Vim than my colleagues in other
editors and IDEs. Colleagues across the company use Vim, Emacs, VSCode,
QtCreator, and Code::Blocks. The Windows developers are all on Visual Studio
naturally. I haven't noticed being slower than any of them. The above plugins
are enough for the odd rename-refactor I have to do, and anything more
substantial is so infrequent, that doing it manually doesn't really have an
impact. Also, developing on Linux, I always feel like any graphical
application will just disintegrate or cause an unrecoverable freeze in the
graphics driver at any random keystroke.

Back in the day I had to make do with just ctags, cscope and debugging
straight from the commandline, lol. I do believe that Stallman's refusal to
allow easily plugging into GCC's AST, like one can just use clang for
indexing, held back C++ development tools on the Linux platform significantly.
Eclipse's CDT, KDevelop, Anjuta, Code::Blocks, NetBeans, etc. - they all
suffered from having to write their own C++ indexers that were always inferior
to getting semantic information straight from the compiler. I'm extremely
grateful to the open-source community for the continuing work on development
tools, and try to donate where I can. Watching the development tools landscape
change over the years has been interesting - things don't so much improve, as
they evolve chaotically with an overall trend towards improvement. Like
anything else on this platform. So far many IDEs have come and gone, but Vim
is eternal.

I will say that using Vim is entirely up to your taste, it doesn't seem to be
substantially faster or slower than an IDE, so use what you like. It is much
cheaper than Qt Creator or CLion (AFAIK for both you need a license to develop
commercial software), so that might be a factor for you. Companies tend to
have a big Windows development team, with a few Linux developers, so they buy
bulk Visual Studio licenses and individual Linux IDE licenses, making the
latter end up costing more per developer.

~~~
jcelerier
> It is much cheaper than Qt Creator or CLion (AFAIK for both you need a
> license to develop commercial software),

Qt Creator is GPLv3 ([https://github.com/qt-creator/qt-
creator/blob/master/LICENSE...](https://github.com/qt-creator/qt-
creator/blob/master/LICENSE.GPL3-EXCEPT)). You can do whatever you want with
it.

~~~
Asooka
Ah, I see. I last looked into using Qt Creator around 2015 and it seems this
license change is from 2016. The company I worked for at that time said from
their reading of the license we need a commercial license and asked if I could
please pick something else. If I had just checked it out a year later, hah.

------
parhamn
Is there a LSPs in a box somewhere yet?

~~~
Lio
Currently I think the coc.vim plugin is as close as you can get. It has
installers for LSP servers and VSCode extensions.

You might also have good luck with a curated vim distribution such as
SpaceVim[1], where everything should be pre-installed for you.

Later, NeoVim 0.5 is going to have LSP out of the box[2]. So things are very
positive.

[1] [https://spacevim.org/](https://spacevim.org/)

[2] [https://neovim.io/roadmap/](https://neovim.io/roadmap/)

------
wffurr
I didn't think setting up YCM was too bad. It also uses clangd as the
completion engine for C++.

------
versatran01
Just no

------
scott31
Closed the page when I saw cmake mentioned

~~~
benreesman
What should we be using? I’ve had nothing but trouble with Bazel and Buck (I’m
a Buck committer). autotools is notoriously painful. Hand-written makefiles
can be nice for smaller projects but get cumbersome with bigger projects.

What am I missing?

~~~
dgellow
For small personal projects I started using dds: [https://github.com/vector-
of-bool/dds](https://github.com/vector-of-bool/dds)

It's still very very young and in development, so not ready for prime time,
but it "just works" and doesn't make me feel stupide the way CMake does...

~~~
benreesman
Thanks for the pointer, I'll take a look. CMake is definitely one of those
tools where I look at the last project I was working on when I can to remember
how to do stuff.

