10 ms·

"To round up, C++ does not dictate about its tooling, which basically gives lot of choices and flexibility. But at the same time it is making it complex for beg

"To round up, C++ does not dictate about its tooling, which basically gives lot of choices and flexibility. But at the same time it is making it complex for beginners to come in to projects and start projects with it." This was a big problem for me when I first started using C++. I don't remember it being too bad when I was just working on small projects and things I wanted to do at school. The problems started when moving past the "1-person" projects. Want to contribute to other projects? Chances are they all have very different build setups and configurations when it comes to building, testing, dependency management. That adds some friction even before you start taking a look at the actual code-base. I understand that a lot of these problems can occur for languages as old as C++, but I wish the tooling was a little more opinionated and worked a little better at guiding newcomers into doing things in a nicer manner.

bluGill 8y ago
C++ is commonly used for large complex projects. The problem with opinions is eventually you come across something that the opinion will not allow. For a small project an opinionated build system makes things easier and you essentially never run across something that can't work. For very large projects that is not true and so you end up fighting opinions in some place.
- anuragsoni 8y ago
  I completely agree, hence the reason I only talked about the experience for new comers. Maybe tools like conan[1], vcpkg[2] etc will help improve the situation for newcomers. [1] https://conan.io/ https://conan.io/ [2] https://github.com/Microsoft/vcpkg https://github.com/Microsoft/vcpkg
- islon 8y ago
  Having opinions != removing choices One can have an opinionated, canonical build system and still allow unorthodox things.
  - drharby 8y ago
    But having an 'unorthodox' (read: not aligned with the opinion) design pattern then comes at a cost. I favor agnostic build systems specifically to permit the fair democratization of design patterns and to embrace a more earnest diversity of thought.
  - bluGill 8y ago
    The strong the opinion the harder the unorthodox things are. The weaker the opinion the harder it is for newbies to get going. There is a trade off here.
    - wwweston 8y ago
      Seems to me that deep configuration capabilities combined with opinionated defaults address the tradeoff.
- lmm 8y ago
  Examples? As a maven advocate I've commonly seen this claimed ("we have to have an ant build because we need to do x/y/z custom thing") but I've never seen an example that held up under scrutiny. E.g. there's no reason any project would ever need a custom source directory layout. No project needs to run tests before compile (and if you really need build step x to happen before build step y, you can always separate them into separate modules and use the normal "module z depends on module w" functionality that any decent build system will have). I've never seen a case for a custom version-numbering scheme that holds up. I've never seen a case for custom VCS release tags where the benefits actually outweighed the costs. All the custom hacks that make for incomprehensible builds turn out to be replaceable with at most a few lines of code or, in very rare cases, a plugin that follows the normal rules of plugins in that build system.
  - phab 8y ago
    Because legacy. Maybe one can't reorganise the source tree layout because to do so would break our custom tooling / integration systems / interface with proprietary vendor tools. We can't change version numbering schemes because our packages already exist 'in the wild' and can't be changed mid-sequence without causing both technical and user pain. Fundamentally: the codebase has worked perfectly well this way for the last 20 years; what's the business case for changing it (at potentially significant cost) just to be compatible with XYZ new tool that everyone is rallying behind?
    - bdamm 8y ago
      Usually this kind of refactor is something done as the very first task following the last release in a minor series and as the first step in a major new release. Going from version 7.4.32 to 8.0.0? Refactor that source tree, reformat all the code, and start over on the build toolchain! Best of all, make sure some junior dev does the actual checkin for the reformat. In all seriousness, I think this is the only way. Yeah you may have forever to deal with it cross patching but let's face it, for big lumbering code bases, perfect backwards compatibility in the source tree is usually the smallest of issues, and the benefit of using standard tools far outweighs the cost of occasionally reinterpreting back-patches (if they are even possible.)
vanderZwan 8y ago
I suspect a lot of people learn how to use some framework or library that happens to be written in C++. For me it was OpenFrameworks and Cinder during art school. https://openframeworks.cc/ https://openframeworks.cc/ https://www.libcinder.org/ https://www.libcinder.org/
hipokampa 8y ago
All C/C++ projects I have ever seen used either cmake or autoconf build system. It's pretty standard.
- frutiger 8y ago
  While true, some very large projects are exceptions. e.g. Chromium or I imagine things like the NT kernel.
- jandrewrogers 8y ago
  That's an availability bias. While cmake is common in commercial settings, I haven't seen autoconf used outside of open source. I've seen scons and meson both used as well at various companies. Meson seems to be spreading pretty rapidly. After I was introduced to it a few years ago for work, I started using it as my default build system for C++ elsewhere and more C++ devs I know have started using it. I've seen it replace CMake and make at large companies for C++.
  - gshack 8y ago
    Why would one use menson over cmake ?
    - jandrewrogers 8y ago
      Meson is much easier to use and configure for C++, being quite obviously designed specifically with C++ builds in mind. It automagically does the right thing for setting up most C++ build environments by default with virtually no config or quirks you need to learn. It is built on top of Ninja, and generally very fast and efficient. The only real knock against it is that the documentation isn't as good as could be, and it is evolving quickly, but the fact that it often "just works" doing the obvious thing makes it less of an issue. In my experience, setting up a cmake environment has a significantly steeper learning curve and is more work. The tradeoff is that Meson takes a fairly rigorous "one correct way" approach to how you organize your builds. It doesn't prevent you from doing anything functional but what it forces you to do is very sensible, minimizes the potential for issues in diverse environments, and reduces the degrees of freedom Meson has to sort out. A prohibition on unfettered creativity, advisable or not, in how you manage your builds has turned out to be a blessing in my experience because it codifies what are very arguably best practices in code and then makes it easy to implement them. I'm fairly agnostic on build systems -- I've probably used a dozen -- but Meson, even in its relatively youthful state, is the best C++ build system I've used so far in terms of getting things done quickly in a maintainable way that is easy to use for average programmers.
mempko 8y ago
Most projects use CMake now so it seems the community is starting to coalesce around CMake as the "not official" build system.
- zanny 8y ago
  Thats besides the growing number using Meson instead.
  - mempko 8y ago
    I haven't tried Meson, any good articles about it?
  - jcelerier 8y ago
    > https://www.jetbrains.com/research/devecosystem-2018/cpp/ https://www.jetbrains.com/research/devecosystem-2018/cpp/ CMake is the most used build system for C++. Meson doesn't even register. CMake is also 6th fastest growing language on github : https://fossbytes.com/fastest-growing-languages-in-2018-github/ https://fossbytes.com/fastest-growing-languages-in-2018-gith...
  - tpush 8y ago
    Meson seems to be more of a thing in certain Linux circles (e.g. Gnome/Freedesktop, but not KDE), but outside of that CMake seems reign supreme.
  - pjmlp 8y ago
    Meson is hardly used outside GNU/Linux.
sl1ck731 8y ago
I ran into this trying to get into it about 3 weeks ago. I'm so used to things like npm, ruby gems, go packages, pip that it felt like a huge task just to get something built or settle on a way for me to build mine. Even grabbing libraries from github, I was unsure if I should grab just the headers and DLLs, or import the entire tree and mashup my build scripts with theirs. I wish I had stayed with it since college but now I feel I have to reach for something like Go or Rust just to get something shareable in reasonable time purely because of the tooling, whereas I would really like to use the C++ language itself specifically for working with win32.
- lmm 8y ago
  Making Rust work nicely with win32 is probably less effort (and more valuable) than getting enough momentum behind a good dependency manager for C++.
  - ModernMech 8y ago
    Rust works great on Windows. I use it every day. Is there anything specifically you had in mind that needs to be improved? Off the top of my head there is some tooling work that needs to be done, but cargo and rustup handle compiling, versioning, and dependency management flawlessly imo.
    - tomsmeding 8y ago
      Person you're replying to probably means the win32 API, i.e. writing GUI applications for windows in Rust.
  - Const-me 8y ago
    > work nicely with win32 is probably less effort Gonna be very hard to do. For the last 15+ years COM is essential part of WinAPI, and too many things in Rust conflict with COM: ownership, OOP, virtual tables, inheritance, they all too different. Not just in Rust, in all languages, actually. You only have 2 good choices for complex platform-dependent windows development: either C++, or a microsoft's language with COM support embedded deep in the runtime, like VB6 or VBScript or .NET.
salawat 8y ago
I do not understand the mentality of "opinionated" frameworks or tools being a good thing, and the trend toward said frameworks disturbs me greatly. What people call "opinionated" is nothing more than something being "architected". Someone has made a bunch of decisions for you that down the road you have no idea whether or not it will actually be good for you. Using these types of frameworks short-circuits the process of being able to understand the nuances of building software. It's the apartment building or high rise of software development. It turns design of your system from a personal journey toward the solution of your problem into little more than assembling linking logs. I can understand the argument for an opinionated toolbox, but not for wanting base tooling itself to be opinionated.
- lmm 8y ago
  A framework that gives you all the choices that you have without it will suffer the inner-platform effect and end up becoming just as complicated to use as the thing it was supposed to help you with. The whole point of a framework is to make certain decisions for you, to make certain paths easier by closing off other possibilities. If you don't trust the framework to make good choices for you, you're better off not using it.
  - gdy 8y ago
    Not quite. https://en.m.wikipedia.org/wiki/Convention_over_configuration https://en.m.wikipedia.org/wiki/Convention_over_configuratio...
- anuragsoni 8y ago
  I'm curious, what would you consider base tooling in the context of a package manager/build tool? I don't think i made it clear enough with my comment, but I was thinking of tooling akin to Rust's cargo, OCaml's `dune + opam`, etc
- Jare 8y ago
  > Someone has made a bunch of decisions for you that down the road you have no idea whether or not it will actually be good for you Opinionated also means that these decisions will be the same in other places/projects I may join. In the medium and long term, that advantage may easily offset the value of custom decisions.
computerex 8y ago
Make was pretty ubiquitous and standardized.. I know in the Windows world there can be a lot of chaos but building from source has been a method of installing software on linux for a very long time.
freedomben 8y ago
You may want to look at Qt. Qt brings a wide array of standard tooling, starting with `qmake`. It also has tons of libraries far beyond just graphical ones (most people don't know that). If you go with Qt flavored C++, the "standard" tooling story gets better. Tho, it still won't be anything like ruby or node. Some Qt projects opt for cmake over qmake, for example. But at least getting your project bootstrapped is much simpler/faster.
- kodablah 8y ago
  I went from 0 C++ work/projects to a quality production one right away w/ Qt Creator, their docs, and general bring-you-up-to-speed-on-modern-c++ docs on the web. I only had minimal experience from a decade ago in C++. Very approachable if you are familiar w/ other languages and are the reading type.
  - ibrault 8y ago
    +1 on the Qt docs. In my personal opinion, and as someone who's a read-the-docs-to-learn type, they are the best documentation I've come across yet.
  - freedomben 8y ago
    Completely agree, I had a similar experience. My team found ourselves liking the Qt approach so much that we started using it for headless projects too, including our server (which used protobufs). Qt is so useful.
- ibrault 8y ago
  CMake has fantastic support for Qt. Decided to add a Qt GUI to a personal project with an existing CMake build setup and the integration was very painless, just ~4 lines added. Finding the solution was a little tougher, however, since nearly all documentation assumes a QtCreator + qmake configuration.
laythea 8y ago
This is true. Whats even worse, is when you downloads some stuff on GitHub to play around and learn from, and then you get frustrated by lack of ability to build the darn thing! #beentheredonethat
pianoben 8y ago
This is why I'm so happy about Bazel lately! It cleanly solves a number of tooling pain points for me: - Cross-platform builds mostly "just work" - Package management, while not painless, is a tractable problem. You can teach your build how to incorporate libraries from tarballs, local filesystem, git repositories, et. - Support for common toolchains (gcc, clang, msvc, android, ios) is built-in! After the hellscape that is CMakeLists.txt, Bazel is such a breath of fresh air. I'd encourage anyone looking at C++ for new projects to give it serious consideration.
deleted 8y ago
[deleted]

bluGill 8y ago

C++ is commonly used for large complex projects. The problem with opinions is eventually you come across something that the opinion will not allow. For a small project an opinionated build system makes things easier and you essentially never run across something that can't work. For very large projects that is not true and so you end up fighting opinions in some place.

anuragsoni 8y ago
I completely agree, hence the reason I only talked about the experience for new comers. Maybe tools like conan[1], vcpkg[2] etc will help improve the situation for newcomers. [1] https://conan.io/ https://conan.io/ [2] https://github.com/Microsoft/vcpkg https://github.com/Microsoft/vcpkg
islon 8y ago
Having opinions != removing choices One can have an opinionated, canonical build system and still allow unorthodox things.
- drharby 8y ago
  But having an 'unorthodox' (read: not aligned with the opinion) design pattern then comes at a cost. I favor agnostic build systems specifically to permit the fair democratization of design patterns and to embrace a more earnest diversity of thought.
- bluGill 8y ago
  The strong the opinion the harder the unorthodox things are. The weaker the opinion the harder it is for newbies to get going. There is a trade off here.
  - wwweston 8y ago
    Seems to me that deep configuration capabilities combined with opinionated defaults address the tradeoff.
lmm 8y ago
Examples? As a maven advocate I've commonly seen this claimed ("we have to have an ant build because we need to do x/y/z custom thing") but I've never seen an example that held up under scrutiny. E.g. there's no reason any project would ever need a custom source directory layout. No project needs to run tests before compile (and if you really need build step x to happen before build step y, you can always separate them into separate modules and use the normal "module z depends on module w" functionality that any decent build system will have). I've never seen a case for a custom version-numbering scheme that holds up. I've never seen a case for custom VCS release tags where the benefits actually outweighed the costs. All the custom hacks that make for incomprehensible builds turn out to be replaceable with at most a few lines of code or, in very rare cases, a plugin that follows the normal rules of plugins in that build system.
- phab 8y ago
  Because legacy. Maybe one can't reorganise the source tree layout because to do so would break our custom tooling / integration systems / interface with proprietary vendor tools. We can't change version numbering schemes because our packages already exist 'in the wild' and can't be changed mid-sequence without causing both technical and user pain. Fundamentally: the codebase has worked perfectly well this way for the last 20 years; what's the business case for changing it (at potentially significant cost) just to be compatible with XYZ new tool that everyone is rallying behind?
  - bdamm 8y ago
    Usually this kind of refactor is something done as the very first task following the last release in a minor series and as the first step in a major new release. Going from version 7.4.32 to 8.0.0? Refactor that source tree, reformat all the code, and start over on the build toolchain! Best of all, make sure some junior dev does the actual checkin for the reformat. In all seriousness, I think this is the only way. Yeah you may have forever to deal with it cross patching but let's face it, for big lumbering code bases, perfect backwards compatibility in the source tree is usually the smallest of issues, and the benefit of using standard tools far outweighs the cost of occasionally reinterpreting back-patches (if they are even possible.)

vanderZwan 8y ago

I suspect a lot of people learn how to use some framework or library that happens to be written in C++. For me it was OpenFrameworks and Cinder during art school. https://openframeworks.cc/ https://openframeworks.cc/ https://www.libcinder.org/ https://www.libcinder.org/

hipokampa 8y ago

All C/C++ projects I have ever seen used either cmake or autoconf build system. It's pretty standard.

frutiger 8y ago
While true, some very large projects are exceptions. e.g. Chromium or I imagine things like the NT kernel.
jandrewrogers 8y ago
That's an availability bias. While cmake is common in commercial settings, I haven't seen autoconf used outside of open source. I've seen scons and meson both used as well at various companies. Meson seems to be spreading pretty rapidly. After I was introduced to it a few years ago for work, I started using it as my default build system for C++ elsewhere and more C++ devs I know have started using it. I've seen it replace CMake and make at large companies for C++.
- gshack 8y ago
  Why would one use menson over cmake ?
  - jandrewrogers 8y ago
    Meson is much easier to use and configure for C++, being quite obviously designed specifically with C++ builds in mind. It automagically does the right thing for setting up most C++ build environments by default with virtually no config or quirks you need to learn. It is built on top of Ninja, and generally very fast and efficient. The only real knock against it is that the documentation isn't as good as could be, and it is evolving quickly, but the fact that it often "just works" doing the obvious thing makes it less of an issue. In my experience, setting up a cmake environment has a significantly steeper learning curve and is more work. The tradeoff is that Meson takes a fairly rigorous "one correct way" approach to how you organize your builds. It doesn't prevent you from doing anything functional but what it forces you to do is very sensible, minimizes the potential for issues in diverse environments, and reduces the degrees of freedom Meson has to sort out. A prohibition on unfettered creativity, advisable or not, in how you manage your builds has turned out to be a blessing in my experience because it codifies what are very arguably best practices in code and then makes it easy to implement them. I'm fairly agnostic on build systems -- I've probably used a dozen -- but Meson, even in its relatively youthful state, is the best C++ build system I've used so far in terms of getting things done quickly in a maintainable way that is easy to use for average programmers.

mempko 8y ago

Most projects use CMake now so it seems the community is starting to coalesce around CMake as the "not official" build system.

zanny 8y ago
Thats besides the growing number using Meson instead.
- mempko 8y ago
  I haven't tried Meson, any good articles about it?
- jcelerier 8y ago
  > https://www.jetbrains.com/research/devecosystem-2018/cpp/ https://www.jetbrains.com/research/devecosystem-2018/cpp/ CMake is the most used build system for C++. Meson doesn't even register. CMake is also 6th fastest growing language on github : https://fossbytes.com/fastest-growing-languages-in-2018-github/ https://fossbytes.com/fastest-growing-languages-in-2018-gith...
- tpush 8y ago
  Meson seems to be more of a thing in certain Linux circles (e.g. Gnome/Freedesktop, but not KDE), but outside of that CMake seems reign supreme.
- pjmlp 8y ago
  Meson is hardly used outside GNU/Linux.

sl1ck731 8y ago

I ran into this trying to get into it about 3 weeks ago. I'm so used to things like npm, ruby gems, go packages, pip that it felt like a huge task just to get something built or settle on a way for me to build mine. Even grabbing libraries from github, I was unsure if I should grab just the headers and DLLs, or import the entire tree and mashup my build scripts with theirs. I wish I had stayed with it since college but now I feel I have to reach for something like Go or Rust just to get something shareable in reasonable time purely because of the tooling, whereas I would really like to use the C++ language itself specifically for working with win32.

lmm 8y ago
Making Rust work nicely with win32 is probably less effort (and more valuable) than getting enough momentum behind a good dependency manager for C++.
- ModernMech 8y ago
  Rust works great on Windows. I use it every day. Is there anything specifically you had in mind that needs to be improved? Off the top of my head there is some tooling work that needs to be done, but cargo and rustup handle compiling, versioning, and dependency management flawlessly imo.
  - tomsmeding 8y ago
    Person you're replying to probably means the win32 API, i.e. writing GUI applications for windows in Rust.
- Const-me 8y ago
  > work nicely with win32 is probably less effort Gonna be very hard to do. For the last 15+ years COM is essential part of WinAPI, and too many things in Rust conflict with COM: ownership, OOP, virtual tables, inheritance, they all too different. Not just in Rust, in all languages, actually. You only have 2 good choices for complex platform-dependent windows development: either C++, or a microsoft's language with COM support embedded deep in the runtime, like VB6 or VBScript or .NET.

salawat 8y ago

I do not understand the mentality of "opinionated" frameworks or tools being a good thing, and the trend toward said frameworks disturbs me greatly. What people call "opinionated" is nothing more than something being "architected". Someone has made a bunch of decisions for you that down the road you have no idea whether or not it will actually be good for you. Using these types of frameworks short-circuits the process of being able to understand the nuances of building software. It's the apartment building or high rise of software development. It turns design of your system from a personal journey toward the solution of your problem into little more than assembling linking logs. I can understand the argument for an opinionated toolbox, but not for wanting base tooling itself to be opinionated.

lmm 8y ago
A framework that gives you all the choices that you have without it will suffer the inner-platform effect and end up becoming just as complicated to use as the thing it was supposed to help you with. The whole point of a framework is to make certain decisions for you, to make certain paths easier by closing off other possibilities. If you don't trust the framework to make good choices for you, you're better off not using it.
- gdy 8y ago
  Not quite. https://en.m.wikipedia.org/wiki/Convention_over_configuration https://en.m.wikipedia.org/wiki/Convention_over_configuratio...
anuragsoni 8y ago
I'm curious, what would you consider base tooling in the context of a package manager/build tool? I don't think i made it clear enough with my comment, but I was thinking of tooling akin to Rust's cargo, OCaml's `dune + opam`, etc
Jare 8y ago
> Someone has made a bunch of decisions for you that down the road you have no idea whether or not it will actually be good for you Opinionated also means that these decisions will be the same in other places/projects I may join. In the medium and long term, that advantage may easily offset the value of custom decisions.

computerex 8y ago

Make was pretty ubiquitous and standardized.. I know in the Windows world there can be a lot of chaos but building from source has been a method of installing software on linux for a very long time.

freedomben 8y ago

You may want to look at Qt. Qt brings a wide array of standard tooling, starting with `qmake`. It also has tons of libraries far beyond just graphical ones (most people don't know that). If you go with Qt flavored C++, the "standard" tooling story gets better. Tho, it still won't be anything like ruby or node. Some Qt projects opt for cmake over qmake, for example. But at least getting your project bootstrapped is much simpler/faster.

kodablah 8y ago
I went from 0 C++ work/projects to a quality production one right away w/ Qt Creator, their docs, and general bring-you-up-to-speed-on-modern-c++ docs on the web. I only had minimal experience from a decade ago in C++. Very approachable if you are familiar w/ other languages and are the reading type.
- ibrault 8y ago
  +1 on the Qt docs. In my personal opinion, and as someone who's a read-the-docs-to-learn type, they are the best documentation I've come across yet.
- freedomben 8y ago
  Completely agree, I had a similar experience. My team found ourselves liking the Qt approach so much that we started using it for headless projects too, including our server (which used protobufs). Qt is so useful.
ibrault 8y ago
CMake has fantastic support for Qt. Decided to add a Qt GUI to a personal project with an existing CMake build setup and the integration was very painless, just ~4 lines added. Finding the solution was a little tougher, however, since nearly all documentation assumes a QtCreator + qmake configuration.

laythea 8y ago

This is true. Whats even worse, is when you downloads some stuff on GitHub to play around and learn from, and then you get frustrated by lack of ability to build the darn thing! #beentheredonethat

pianoben 8y ago

This is why I'm so happy about Bazel lately! It cleanly solves a number of tooling pain points for me: - Cross-platform builds mostly "just work" - Package management, while not painless, is a tractable problem. You can teach your build how to incorporate libraries from tarballs, local filesystem, git repositories, et. - Support for common toolchains (gcc, clang, msvc, android, ios) is built-in! After the hellscape that is CMakeLists.txt, Bazel is such a breath of fresh air. I'd encourage anyone looking at C++ for new projects to give it serious consideration.

deleted 8y ago

[deleted]