Hacker News Reader

Comment by anuragsoni | Hacker News Reader

"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.

View on HN

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.

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/

[2] https://github.com/Microsoft/vcpkg

Having opinions != removing choices

One can have an opinionated, canonical build system and still allow unorthodox things.

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.

Seems to me that deep configuration capabilities combined with opinionated defaults address the tradeoff.

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.

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?

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.)

Some of these codebases have 10s of millions of lines if not more. Such a refactoring could take years.

The benefit of using widely supported tooling is even greater for large codebases. Automated reformatting is easy, and moving code around isn't that hard if it's going hand in hand with a build system that supports it.

Staying in the cooking pot of ever larger proprietary and exotic hacks is how organizations grind to a halt.

> The benefit of using widely supported tooling is even greater for large codebases.

Your assertion really depends on your definition of "widely supported". Jumping from fad to fad, however, is only effective as a way to waste time.

>Staying in the cooking pot of ever larger proprietary and exotic hacks is how organizations grind to a halt.

Using established build systems for C++, whether autotools or even plain makefiles, ensures that the project doesn't suffer from bit rot and developers can focus om developing code instead of wasting their time trying out every flavor of the month. And do note that the main reason C++ hasn't adopted any official build system is that each and every flavour of the month ends up being very horrible and very hard to maintain.

Yes, including CMake. If a build system is known for telling essentially all users that they are doing it wrong, that means the build system is the problem.

> Because legacy

Yes. And there are codebases that are going to outlive thee shiny tool of the month (or the decade, even).

> 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.

That hardcodes the source layout? I don't buy that a tool that's being sold for money would do that (precisely because there's no standardization in the C++ world; any tool that wants to have more than 1 customer will have to support more than 1 directory layout), and if the tools are internal then by definition you have the ability to make changes to them.

> 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?

Well, if you make adopting good tooling in C++ harder than switching to a language that already has good tooling, don't be surprised when developers do that.

> and if the tools are internal then by definition you have the ability to make changes to them.

I happen to work in a shop with problems that look somewhat like this. We have a non-trivial amount of legacy code, that we just don't have the resources or motivation to fix. In those cases, we've found that the cohesion of doing it the same (wrong) way everywhere is easier to work with than doing it the new way in some places.

> I don't buy that a tool that's being sold for money would do that

If you work with proprietory hardware (think FPGAs), if you want to use the hardware, you have to use proprietory vendor tools, whether you want to or not.

> if the tools are internal then by definition you have the ability to make changes to them.

This misses the point. Having the technical ability to modify the tool does not equal having the real-world-practicability, business-case-defendable ability to change the tool.

> Well, if you make adopting good tooling in C++ harder than switching to a language that already has good tooling

The point is that in a 20 year, n-million line codebase, neither is "easy", and the pragmatic solution is to do neither.

On the JVM you have the luxury of a third way which is Gradle. Convention over configuration, standardized builds but with flexibility if needed.

> 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.

In my experience, this just means they don't know how to do custom thing in Maven. Maven is very configurable; it can do pretty much anything you want, as long as you're willing to throw enough XML at it.

And if you are throwing a ton of XML at it, and your pom file starts to look like a nuclear disaster, that's a good sign that the custom thing you're doing isn't such a good idea after all.

Back in the days when we used Maven, we had an involved asset building system. It was very hard to shoehorn this into Maven's fixed lifecycle phases (they might be customizable now, I don't know) to the point where we had a Maven plugin so powerful, it eventually made Maven redundant.

> we had an involved asset building system. It was very hard to shoehorn this into Maven's fixed lifecycle phases (they might be customizable now, I don't know)

They're not customizable, by design. I find people with this problem tend to be missing the option of using a multi-module project: if you need to build A, B that depends on A, C that depends on B and so on, the right way to model that in maven is to have those things in separate modules with dependencies between them. That way your dependency graph lives in the normal maven representation that anyone working on it can understand, and the within-module phase ordering continues to be what anyone working on will expect (compile before test before package, etc.)

As one (slightly abnormal) example that I've worked on. We would build the meat of the solution, then run our tests. Upon success, we'd generate language bindings (think swig), compile them and run API tests against those. The languages included C++, C#, Java and Excel 12 bindings (which required their own .cpp files). I can easily see this type of special case worm its way in to larger projects and be valid, yes.

> Upon success, we'd generate language bindings (think swig), compile them and run API tests against those. The languages included C++, C#, Java and Excel 12 bindings (which required their own .cpp files).

Sure, so you need support for a multi-module project. Any serious build tool will have that.

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.

Making Rust work nicely with win32 is probably less effort (and more valuable) than getting enough momentum behind a good dependency manager for C++.

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.

Person you're replying to probably means the win32 API, i.e. writing GUI applications for windows in Rust.

I'm sure Rust works great :) But vcpkg was made by Microsoft and I suspect is rather easy to get working on that platform. On the other hand, I've used conan and had no problem e.g. getting FFmpeg working. And, thanks to conan's awesomeness, I can even make it work with clang on windows -- so that e.g. I can use all the latest c++17 features on a library like Boost.Hana and range-v3 (of Eric Niebler fame).

> 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.

Delphi, JavaScript, Python and C++ Builder as well.

I think Delphi and C++ Builder were only good enough while WinAPI meant “C API”.

JavaScript is OK for platform-independent development with electron. For platform-specific i.e. WinRT not that good, .NET is just better, and MS put the JS libraries in maintenance mode: https://github.com/winjs/winjs

Python was never good. I’ve tried using winapi through C interop a few times, didn’t like it at all despite what I did wasn’t even too complex.

Delphi and C++ Builder have first class support for COM and UWP. In fact, both had better COM support before VB migrated from VBX to COM with VB 6.0.

JavaScript has first class support on UWP. Of course WinJS is in maintenance BB mode. The future of JavaScript on UWP are PWA apps, with direct access to UWP APIs, no more need for WinJS, which was a Windows 8 library.

Python has supported COM with help from PyWin32 since ages. Hardly any different from VBScript.

> first class support for COM and UWP

When I search “Delphi DirectX”, I only find some Russian website last updated in 2009 and offering Direct3D 10.1 bindings. The newest one is 12, the oldest supported is 11.2.

When I search “Delphi Media Foundation” it’s better, finds bindings updated 4 years ago.

These COM-based technologies are among reasons why I sometimes still pick C++ even for new projects.

Also, in both cases just bindings are not enough, the frameworks are complex, need code samples, stackoverflow community, sometimes books, etc. There’re tons of resources on using these from C++, many from C#, very few for the rest of the languages.

> JavaScript has first class support on UWP

Win32 GDI also has first class support on Win10, just because it’s supported doesn’t mean it will go anywhere. I have doubts MS will continue with that support, they haven’t achieved much and need to do something else, e.g. include CEF in the OS.

> Hardly any different from VBScript.

The difference is that VBScript _is_ COM. All VBScript variables are VARIANT, all strings are VARIANT of VT_BSTR type, and all objects are IDispatch. The interop is not required, COM is already native to the runtime. I can write a COM server in a page long text file with *.wsc extension and VBScript inside, register it with regsvr32.exe, and consume from any language, e.g. `#import "progid:..."` in VC++. I’m not sure you can do same in Python.

So I talk about COM, and you move the goal posts about DirectX in particular, that only implements a subset of COM, which requires writing wrappers by hand, including in .NET, hence Managed DirectX, XNA and SharpDX projects.

Apparently you missed the news regarding PWAs in Windows and its support for native UWP. Again, WinJS got dropped, because it was tied to the Windows 8 programming model, which got improved on Windows 8.1, only to be replaced by UWP on Windows 10.

Win32 GDI actually has "we wish you were all using Win2D and DirectDraw" support on Windows 10.

Here are some examples of automating Excel with Python, http://pbpython.com/windows-com.html, hardly any different from using VBA.

> you move the goal posts about DirectX in particular

In my first comment I wrote that COM became an essential part of WinAPI. Excel runs on Windows but it’s not Windows. DirectX on the other hand is in OS kernel, mayor parts are dxgkrnl.sys. Same applies to media foundation, Windows shell and clipboard, WMI, and many other OS components.

> which requires writing wrappers by hand, including in .NET, hence Managed DirectX, XNA and SharpDX projects.

Right, and all except SharpDX are first-party i.e. made by MS. MS made even more wrappers, WPF, Direct2D and UWP are also manually written wrappers around D3D 9 or 11.

How many wrappers MS made for Delphi or C++ builder?

> you missed the news regarding PWAs in Windows and its support for native UWP

I’m a bit skeptical about the technology.

> examples of automating Excel with Python

Simple IDispatch not that hard even in pure C. It’s more advanced things that require better support for COM: servers, events-callbacks, data structures like arrays and dictionaries, etc.

> too many things in Rust conflict with COM

Do they? COM in its essence defines two things:

1. A binary ABI for interoperability of components written in whatever language. 2. Reference-counting mechanism and "casting" mechanism (IUnknown).

MS has an article that shows how to build a COM component from the ground-up using only plain C structs containing function pointers (which is how vtables are implemented anyway: array of function pointers). What you think of inheritance can be implemented with a struct containing nested structs of function pointers. Etc.

It's not insurmountable, e.g., PyWin32 has utilities for both consuming and implementing COM components.

> COM in its essence defines two things

COM is quite a lot of things. Also threading model, date-time-currency formats, late binding/dynamic dispatch/scripting, type info both runtime and design time, IPC, RPC, security, and more.

> What you think of inheritance can be implemented with a struct containing nested structs of function pointers

What I think of inheritance in the context of COM is called “aggregation” and it’s more complex than that.

> It's not insurmountable

It’s not, but you’ll spend ~2x more time doing that compared to C++, and ~4x more time compared to VBScript or .NET.

Update: that 2x-4x is for implementation. For consumption C++ and .NET are close, but anything else is more complex due to FFI in between. C++ or VBScript don’t need FFI, .NET runtime is designed around many key parts of COM e.g. they have reused HRESULT’s and type info format.

I have high hopes for C++ modules. Seems like that could be a good catalyst for a standard C++ package manager.

Rust is still miles away from providing any useful COM/UWP tooling.

> 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.

Honestly this is something that apt (et al.) make so easy on Linux distros that when you move to Mac or Windows you just have hard time believing people still in 2018 have to _deal with this shit_ (installing libraries and their headers by downloading each one separately and running an "installer" and trying to figure out where it put everything)

Like, why. It's one of the principle things keeping me away from developing on Windows for the last 10 or 15 years, the absolute lack of standards with regards to dev package management. Every time I decide I need to get something working on Windows it's an incredible pain in the ass compared to Ubuntu. Oh, now go to THIS website and download this installer and run it, now this one, now this one. And figure out for each one where it decided to put the headers. Now copy the DLLs around, etc. (Yes, there is system32 and Program Files but installers don't adhere to this by any means, and discovery via a build system is not given.) It's just barely worth it, and people only put up with it because of the huge user base. Honestly, for small projects I've found it easier to install MingW32 under Linux and cross-compile instead of working on Windows, it's that much of a pain.

At least Mac has Homebrew and Windows has a couple of good solutions now I guess (chocolatey, who came up with that name), but they are not officially supported and that is sad. I understand, they don't want to pay an army of people to package open source software full time, which effectively is what keeps Debian and Fedora going.. but they should. I would say it's one of principle reasons then end up doing something like providing an Ubuntu environment on Windows .. it's not just that people wanted a Unix-like environment, it's that they wanted _package management_.

Windows continues to move in the right direction with package management. Your comment "not officially supported" may not be correct depending on your definition of official. Package management is native in win10 with OneGet, and PMs like scoop have been improving in quality and reliability to the point that I don't even think about them anymore.

I do agree that there is a lot of room for standardizing tool chain and dependency install workflows, but the tools themselves are of high quality now imo.

I am glad it's getting better.

> chocolatey, who came up with that name

The chocolatey repo (https://github.com/chocolatey/choco/wiki/History) explains the name as a pun based on the previous package manager NuGet: "Chocolatey started out as a joke because everyone loves Chocolatey nougat (nuget)."

For what it's worth, I develop almost exclusively on Ubuntu, but built-in package management is no panacea.

You get one version of each package, and it is often years out of date. If you need a newer version you'll have to install it yourself and then try to navigate how to get your projects to use your local version. For any popular package that is still undergoing a fair amount of change it is likely that eventually some project you want to build will need a newer version than the one your distro provides.

So you still need a solution to the versioning problem separate from the distro packaging environment, at least for development.

For building my (rather small) projects for Windows I use MSYS2 [0]; it uses pacman for package management and has quite a big library of ready binaries.

[0] http://www.msys2.org/

I've been using it too. It's getting better, finally, thank goodness ;) Still a far cry from what is offered on Linuxes but so much better than nothing.

How is this problem fixed on Linux?

Headers/libraries on an Ubuntu LTS may be years out-of-date.

Am I supposed to just download a tar.gz and do the configure/make/make install dance to /usr/local or /opt or something for each dependency that I need a more current version of?

Even worse - what if my deployment target is 3-4 years older than the machine I'm developing/compiling on?

I don't think anything is "solved" with a traditional UNIX environment. Not even close.

> Am I supposed to just download a tar.gz and do the configure/make/make install dance to /usr/local or /opt or something for each dependency that I need a more current version of?

No, you're (usually)supposed to stick with the out of date version rather than the shiny new version. Doing otherwise is taking on the responsibilities of a distro maintainer, usually not consciously.

> Even worse - what if my deployment target is 3-4 years older than the machine I'm developing/compiling on?

Either use the older version for developing or at least have a version of that environment for CI.

Have you looked at vcpkg? It's the simplest way to use third party libraries on Windows in my experience. Many popular open source libraries are supported out the box by vcpkg now.

I didn't but some of the libraries I needed at the time don't appear to be present. The reason I wanted to use C++ specifically was API hooking and the Windows ETW api. I don't see any of the projects like Detours present so unfortunately it wouldn't have helped me in this case.

It does look promising but because of the mess I'll probably gravitate to another language if I don't need to consume such a low level API.

Someone else has mentioned vcpkg. Another project that gets you closer to Rust or Go in this respect is conan, which I really enjoy using. It's still not as polished as other package managers (e.g. maven), but for a lot of very useful libraries, on a reasonable platform (recent OS, recent compiler) and for most important libraries (FFmpeg, boost, abseil, range-v3, the list goes on...) you can just add a single line to your conanfile with the version you want and off you go.

And remember -- a lot of the complexity comes from historical reasons AND also allow you to, e.g. run on, say an Atmel 328p or other microcontroller. So the complexity is partly from having such a wide target area.

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.

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.

+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.

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.

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.

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://www.libcinder.org/

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.

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.

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.

Not quite.

https://en.m.wikipedia.org/wiki/Convention_over_configuratio...

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

> 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.

Some subset of those decision are also things which just don't matter, like which side of the road to drive on— the value is in a critical mass of people all doing the same thing more than it is in the merits of either approach.

A lot of stylistic stuff like filesystem layout falls into this bucket.

Bless standard formatters (gofmt, etc) becoming the norm.

Appreciating this lays out the boundaries for the the more borderline stuff. An example of this, IMO, is things like unit testing and mocking frameworks. Most are pretty similar, and offer similar functionality, but perhaps with slight differences in capability or approach to solving common corner cases.

You might have some highly-specific need which demands a particular tool, but it's likely that you're best accepting whatever is most popular in your chosen ecosystem (gtest for C++, nose/tox for Python, etc).

With that mentality, your best bet is to write in assembly language.

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.

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

Thats besides the growing number using Meson instead.

I haven't tried Meson, any good articles about it?

> 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-gith...

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.

Meson is hardly used outside GNU/Linux.

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

While true, some very large projects are exceptions. e.g. Chromium or I imagine things like the NT kernel.

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++.

Why would one use menson over cmake ?

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.

How would you evaluate Meson as a build system for C projects? I _think_ C and C++ build process is very similar, but I only work professionally with C, so maybe there are some quirks to C++ I am not aware of.

Basically, I wonder if you would recommend Meson as a build system for a mostly C project with maybe some C++ parts and some extra external tools ran on top.

I agree with your presumption that it almost certainly should work well but I haven't actually used it for a C project. Offhand, I can't think of anything that I would expect to break.

Plenty of C projects use Meson: https://mesonbuild.com/Users.html

Menson's syntax is very similar to Cmake, would u say it's a better/faster version of Cmake ?

DPDK switched to meson/ninja. It's great.

Has anyone done a comparison to show what the advantages and disadvantages are of each build system? Seems to me that most people pick one, and they stick with it without knowing much about the other two. In the case of automake, I didn't like it at all, and it felt more like it was geared towards open source projects that need cross compilation. For an internal large project, which is mostly what I work on, I'm curious to know what the advantages and disadvantages are of cmake versus Meson.

I suggest you have a look at OpenSSL.

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

Reply on news.ycombinator.com