I think the primary use case is building the same code on multiple platforms. A developer can write a single CMakeFile and then CMake will generate Makefiles/Ninja files/VS soln files/etc depending on the underlying platform.
I've used CMake for a number of larger projects. When you start having to deal with external dependencies or cross platform support it definitely fills in some of the holes in the C-style build ecosystems
One of the things I've never been a fan of is that for whatever reason, the build steps that you see in basically every project are:
- mkdir ./build
- cd ./build
- cmake configure ../
- make build
Seems like it usually comes in when people try to support building on Windows.
Not sure people "like" it, but they claim it makes the job easier.
Sometimes cmake is optional. That is, one can still type "make" on Linux/BSD and just ignore the cmake files. Unfortunately, that seems to be the less common way to use cmake.
Using cmake on Linux/BSD does seem like overkill. It is not necessary. I share the aversion to learning cmake but always figured complaining about it would not be well-received.
CMake isn’t that bad. The language gets a bad reputation, but there’s honestly not that much to hate about it. Maybe if you’re maintaining thousands of CMake files, then yeah it can probably become a pain. But for most cases it just does what you need it to, and reliably. The “killer” feature is that it can generate Visual Studio solutions, which is a big deal for some projects, and a great asset for cross platform development.
Now what I don’t get is why Meson is so popular. I haven’t dived into it, but from the outside it doesn’t look like all that different from CMake. Seems to me like the vast majority of Meson projects would be better off with CMake just because it’s more mature and well known, but otherwise does the exact same thing.
CMake sucks in a lot of ways but it's the only build system that is mainstream right now that doesn't impose some philosophical idealisms as to how your code should work.
Meson is the next runner up and it should come with a religious text about how the creator thinks software should work.
one thing I'll never stop struggling with isn't cmake but the interaction of it from within the editor. vim-cmake is cool but not always easy to set-up on legacy projects where the build-system has even more technical debt than the code itself. I can't really blame cmake for this though.
For the task of building there aren't many cross-platform abstractions which :
- is easily boostrappable
- works on OS without any kind of POSIX shell
- allow to extract, download, create file / directories in a cross-platform way (cmake extracts 7z, zip, .tar.gz and friends on every platform with a single command)
- allow to quickly parse and generate code with regexps without having to fight with whatever difference between versions of perl, rename, etc. there are on the host system
- does not require "quoting" every flag or source file (seriously, this is just a pain in most more recent BS)
- just works with everything that can be thrown at it and accommodates the project's way of handling dependencies instead of trying to impose its own
- easily allows to find dependencies on systems with no canonical path to look for them
I don't think anyone likes it much, but it's the closest thing to a standardized project / build system thingy in C/C++ land. It has the best IDE support for example.
I suppose different people have different definitions of "ultralightweight" --- because this is actually quite a bit more complexity than I expected. I thought it would be closer to a SAX-style streamer or a thin layer on top of strstr(). This has its own object model etc.
I don't think file number / lines of code is a good measure, you can have perfectly readable code in a single file that is 1000s loc. There are plenty single header file libraries that are larger and are very useful. Perfect example is the stb libraries: https://github.com/nothings/stb
very widely used in the C / C++ community.
They are single header for a single reason: Dead easy to distribute.
> You can have perfectly readable code in a single file that is 1000s loc.
You can if you are dealing with a single concept. JSON parsing is not a single concept. You can easily split that up into more understandable modules. In fact I would wager that any JSON library that has not modularised serialization, deserialization and object building/modification into modules is not doing a good job.
It's not like more c files cost anything. It's not comparable to header-only libs since they will compile to an object file anyway.
I am developing an Apache module that does some authentication stuff, and I needed a way to parse and read JSON in C. I really did not want to deal with doing that myself, and I wanted to avoid any complicated library.
The possibility for Remote Code Execution vulnerability from an unauthenticated user. This should be offloaded into a memory safe language, ideally by a parser that's been battle tested.
Remember that Apache Remote Code Execution bug? No, not Struts, the other one. No, not mod_cgi, the other one. No, not auth_digest the other one.. ad inifinum. These were all caused by so-called "unsafe legacy functions". Just because YOU might not implement them, doesn't mean others won't.
I really don't understand the widespread fear of C/C++ that I see so often. The vast majority of security pitfalls are from using very old functions that don't check input. These are easily caught with linters and scanners. In many cases the compiler itself will warn you if you use them. Don't ignore warnings!
This is cool, but writing configurations in JSON sucks. You need a JSON, YAML, TOML parser to really make it complete and HCL is better IMO. Speed-wise doesn't seem like there would be much difference between C, Go or Rust.
The size of cJSON structure that holds single JSON value is 80 bytes on 64-bit or 32 bytes on 32-bit architecture. Why the author doesn't use union here? Or NAN boxing trick like many JS interpreter do. In case of NAN boxing, single JSON value uses only 8 bytes on both 64-bit and 32-bit architecture.
This creates json, can emit json structurally, and parses json. You don't really need to emit json, printf in some macros is usually enough.
This parser is heavy, creating copies.
But it's much easier to use than jsmn. jsmn needs two loops and special handling of the various types. There's no high-level API to get the values of an array nested in an object. CJson has it, at the cost of copies and 2x memory and slowness.
39 comments
[ 3.1 ms ] story [ 91.7 ms ] threadI have an aversion to learning it because it seems like an abstraction of an abstraction and of little value. But I’d like to change my mind.
(Thanks for this btw, I was looking for something like this)
One of the things I've never been a fan of is that for whatever reason, the build steps that you see in basically every project are: - mkdir ./build - cd ./build - cmake configure ../ - make build
Has no one thought of simplifying that??
Not sure people "like" it, but they claim it makes the job easier.
Sometimes cmake is optional. That is, one can still type "make" on Linux/BSD and just ignore the cmake files. Unfortunately, that seems to be the less common way to use cmake.
Using cmake on Linux/BSD does seem like overkill. It is not necessary. I share the aversion to learning cmake but always figured complaining about it would not be well-received.
Now what I don’t get is why Meson is so popular. I haven’t dived into it, but from the outside it doesn’t look like all that different from CMake. Seems to me like the vast majority of Meson projects would be better off with CMake just because it’s more mature and well known, but otherwise does the exact same thing.
Meson is the next runner up and it should come with a religious text about how the creator thinks software should work.
- is easily boostrappable
- works on OS without any kind of POSIX shell
- allow to extract, download, create file / directories in a cross-platform way (cmake extracts 7z, zip, .tar.gz and friends on every platform with a single command)
- allow to quickly parse and generate code with regexps without having to fight with whatever difference between versions of perl, rename, etc. there are on the host system
- does not require "quoting" every flag or source file (seriously, this is just a pain in most more recent BS)
- just works with everything that can be thrown at it and accommodates the project's way of handling dependencies instead of trying to impose its own
- easily allows to find dependencies on systems with no canonical path to look for them
1. It's widely available (even on Windows). 2. It's not as bad as autotools.
> You can have perfectly readable code in a single file that is 1000s loc.
You can if you are dealing with a single concept. JSON parsing is not a single concept. You can easily split that up into more understandable modules. In fact I would wager that any JSON library that has not modularised serialization, deserialization and object building/modification into modules is not doing a good job.
It's not like more c files cost anything. It's not comparable to header-only libs since they will compile to an object file anyway.
I am developing an Apache module that does some authentication stuff, and I needed a way to parse and read JSON in C. I really did not want to deal with doing that myself, and I wanted to avoid any complicated library.
This is super easy to use, and is just one file.
Are you parsing JWT objects?
A parser written in C shouldn’t be used on something like an authentication library for web services.
Whether or not it makes sense to do it like that is another story, but I don't have control over the design of enterprise architecture.
This creates json, can emit json structurally, and parses json. You don't really need to emit json, printf in some macros is usually enough.
This parser is heavy, creating copies.
But it's much easier to use than jsmn. jsmn needs two loops and special handling of the various types. There's no high-level API to get the values of an array nested in an object. CJson has it, at the cost of copies and 2x memory and slowness.