build systems and code editors\IDE's you use or suggest on Linux?

[malibor]

For the last 2 years I'm using VSCode, since my switch to Linux I continue to use it.

But there are many pitfalls with VSCode, primarily VSCode is not good for C++ development, the biggest issue is that built-in build system is cumbersome to configure, takes a lot of copy\paste of configs resulting is some 4K lines of code only to have solid build configuration which is then again PITA to maintain.

But otherwise it's great code editor.

I'm curious what do you use on Linux, which build system and which IDE\editor.
Just please don't suggest Cmake and Vim, I really hate those 2.

What else is solid for C++?

[kigar64551]

Qt Creator might be worth a look:
https://en.wikipedia.org/wiki/Qt_Creator

Also, Code::Blocks:
https://www.codeblocks.org/

[malibor]

Thank you mentioning Code::Blocks, I'm aware of it and will try it,

But I heard Linux devs use their own build-system\editor\config combos so was curious what this could be.

EDIT:

Actually I'm no so sure about Code::Blocks, latest release is from 2020, what kind of IDE is that which isn't updated for 4 years..

And QT editor is UI designer not code editor isn't?

[George P]

The C::B IDE might be relatively old, but you can and should update the underlying compiler suites that C::B can access.

C::B is similar to VS Code, you have to manually nurse-maid things from time-to-time that the Visual Studio IDE does automatically with each new update.

If'n I were to switch over to Linux I'd start out C::B as my IDE since I've already gotten (semi-) used to tweaking it on Windows.

[TheIdeasMan]

@malibor

Hi

Interesting you have 4KLOC of configuration code, that has to be maintained.

I am not sure why you dislike cmake, it's a solid build system that can do all kinds of things, and seems to be an industry standard these days. I guess the downside is that it is another language to learn. However VSCode can initially setup a cmake project for you, it's a matter of making changes as required. And a lot can be done with a simple setup.

IMO C::B isn't anywhere near as good as VSCode. VScode has lots of plugins to do various things, while C::B seems to be a little too simplistic IMO. C::B doesn't seem to have background compilation to show the red squiggles as one types the code. While it does have TurtleSVN for version control, it doesn't have git, which is a deal breaker for me.

QtCreator is a proper IDE, not just a UI designer. Although doesn't seem to have as many plugins as VSCode, but a lot of people like it, even if they aren't doing Qt.

With vim, it has massive capability compared to other editors, but there are a zillion keystroke combinations to remember. There are ways to mitigate that though, for example I have a vague idea that one can assign macros to a key on the keyboard. Like emacs, I guess it grows on the user over a long period time; people who have been using it for years swear by it.

There is also KDevelop, which IMO is also not as flash as VSCode, but it does have the capability of being able to deal with about 60 different languages / script / markup. It has all the basics: debuggers; various version control systems; make, cmake, qmake etc. It is also under continuing development. One can still use it, even if one isn't running KDE.

https://en.wikipedia.org/wiki/KDevelop
https://apps.kde.org/kdevelop/

Also, Sublime Editor
https://en.wikipedia.org/wiki/Sublime_Text

And Eclipse:
https://eclipseide.org/

Varying reports about Eclipse. My problem with it was when updating Eclipse, I then had to update all the plugins, which became painful. Maybe I wasn't doing right?

[malibor]

@TheIdeasMan

Interesting you have 4KLOC of configuration code, that has to be maintained.

It's because separate config needs to exist for Debug-x64, Debug-x86, Release-x64 and release-x86 in c_cpp_properties.json plus environment and input variables outside these configs.

This file a lone is 424 LOC

There is also tasks.json which is 935 LOC, and settings.json which is 768 LOC, plus launch.json, extensions.json, keybinding.json, cspell.json, bookmarks.json etc. etc.

And all this is for 1 project only, therefore needs to be duplicated for each project.

But I'm now discovering multi-root workspaces with the aim to centralize as much config as possible under parent workspace and to reduce LOC.

I am not sure why you dislike cmake, it's a solid build system that can do all kinds of things, and seems to be an industry standard these days. I guess the downside is that it is another language to learn.

Exactly this, Cmake is like learning a new language, and I find it difficult to learn it, did try and gave up.
documentation and tutorials seems to be lacking, had to google out every issue I stumbled upon.

IMO C::B isn't anywhere near as good as VSCode.

Thank you very much, I've read the rest of your post and you certainly convinced my why C::B is bad compared to VSCode so I think I'll stick with VSCode.

@George P
Comments about C::B from @TheIdeasMan further drove my away from C::B,
I recall trying it on Windows and didn't like it, was considering to try again but it's poorly maintained.

---

I appreciate everyones input, it helped me realize that switch to something else isn't the way to go, except for Cmake, I might consider learning Cmake at some point but...

[George P]

vcpkg works on Windows, MacOS and Linux, and uses CMakes scripts to do its work. Though you don't need to use CMake (or MSBuild) as your build system to make it work.

https://learn.microsoft.com/en-us/vcpkg/get_started/overview

[malibor]

@George P
Yeah vcpkg is great for 3rd party libs, but useless for your own library projects ex. if you maintain a project with multiple separate own library projects that depend on each other.

I'm not sure how easy it would be to turn your library into one manage-able by vcpkg.

[keskiverto]

Spack https://spack.io/ -- "scientific package manager" -- is not an answer to the OP question (nor necessarily "best of the best" in anything), but does hint of some of the hoops. There are many build systems and some the Spack can talk to: https://spack.readthedocs.io/en/latest/build_systems.html

An another detail is that Spack installs every package to distinct directory. (Aww, that sounds almost like Windows.) In order to use package/program/library, one then uses "environment module" to modify shell environment in order to have the thing "on the path". Depending on package, multiple search paths may be modified. for example:
PATH, MANPATH, CMAKE_PREFIX_PATH, PKG_CONFIG_PATH, LD_LIBRARY_PATH, and/or PYTHONPATH.

This is the point of my post:

Of these at least the CMAKE_PREFIX_PATH and PKG_CONFIG_PATH seem to help your build system to find third-party libraries for your build. That is to say that the "pkgconfig metadata" is something that your library could/should provide in order for others to more easily use your library in their projects.

I don't know what the pkgconfig requires, whether it is easier than that vcpkg, nor could vcpkg read/use pkgconfig.