4 ms·

If you use Arch Linux, you get CMake files and headers for every library you can install, built right into the package, as well as all the dependencies you'll n

If you use Arch Linux, you get CMake files and headers for every library you can install, built right into the package, as well as all the dependencies you'll need for those packages. C/C++ with CMake is honestly a joy. It's really wonderful. The issue is that it's not the most popular thing to use right now. The hype train has wandered off into the realms of JS, Go, and Rust. A lot of money goes into super-convenient tooling for these newly relevant languages. So perhaps I've made it clearer as to why C is less popular now.

klodolph 11y ago
I've been using CMake off and on for years now, including recently. I feel no joy using it. The syntax is ridiculous, the semantics are worse, and the documentation is poor, even in 2016. It gets the job done, but it is a royal pain in the butt. Whenever feasible, I'll use something else. These days, that usually means writing a quick build script generator in Python. I've been around for a while, so I remember using a lot of different build tools, from monstrosities like autotools (which has good points), hand-written makefiles, to "modern" designs like Jam, SCons, NAnt. CMake is basically the least usable of all of these (except autotools), but at the same time it is the only one which solves the desired task. I wouldn't say that it's just a matter of money and popularity. C and C++ are both quite popular these days. The problem is that the tooling is so different between platforms. You want to build a shared library? Hah, the process is quite different on Windows, and there are non-trivial differences between OS X and Linux too. You need to change your header files on Windows depending on whether the library is static or dynamic, and you even need to worry about things like "who calls free()" because as soon as you make a DLL you can't be sure that the person calling your code has the same malloc that you do. With JS, Go, and Rust, the toolchain is identical on all platforms, there are no header files, et cetera. We've had decades to try and make C tooling nice and easy, and it simply hasn't happened, despite the language's overwhelming popularity. The most usable solution we've really come up with is writing C on your favorite Linux distro, where you can just apt-get whatever you want and pkg-config it into your build system. But once you want to build on OS X, you get to choose between the insanity of Homebrew or the insanity of building your own packages. On Windows, things are even harder, because suddenly all the shell scripts that propped up your build system stop working. Your experience on Arch just reflects the reality of cross-platform development: it's awesome if you can avoid it. I do most of my development on a Linux system as well and I can reasonably call it a "joy" right up to the point when I need to finish the Windows and OS X ports. I don't think that you can truly experience the horrors of CMake if you stick to Linux. Heck, on Linux, you can hand-write makefiles fairly reasonably, if you know what you're doing.
- spriggan3 11y ago
  On Windows I was rather successful with developing C apps with msys2 which comes with a Posix envirronment and pacman package manager. Most source that use posix compliant apis compile on windows and mingw provides a few handy adapters. It's obviously not going to run docker containers but it's really handy, I was successful compiling quite a lot of c projects from scratch, including some Gtk3 apps.
  - klodolph 11y ago
    Unfortunately, that won't work for me. Compiling with MSC is a requirement, for various reasons.
spriggan3 11y ago
> So perhaps I've made it clearer as to why C is less popular now C is "not popular" (that's relative) because C is verbose, practical C is ugly and just dangerous if not in expert hands. I'm not a fan of Go but Go doesn't have C memory management problems. The complexity of C development is also in the tooling, Cmake, make, autotools , autogen and co ... imagine you're a beginer today , you need to write a server . It's like 4 lines in Go then you just type Go build. With C you'd have to install the proper library, then choose a build tool, then learn another language like make , then learn m4 macros ; then learn to do proper memory management , ... it takes way more than a day to get started, it takes months ... C lacks of a lot of modern features such as namespaces, simple string support, ... C isn't going away, Linux kernel is written in C so it will always be a dependency but explaining why C is the last choice when developing applications is pretty easy. Try writing a JSON api in pure C backed by a NoSQL db , then try the same with Go or Rust. You might be an C expert so ask someone that is a noob in software development to do the same, from scratch and watch the amount of time it takes to do so. Now give him Go to write the exact same thing ...
- jallmann 11y ago
  While the problem space where C would be appropriate has been shrinking, this rant is nonsense. > With C you'd have to install the proper library, then choose a build tool, then learn another language like make , then learn m4 macros ; then learn to do proper memory management What library? The libc that is on every OS? Build tools and Makefiles aren't exclusive to C; any non-trivial project is going to have tooling, no matter the language [1]. Also, if you don't understand memory management, then why do you think starting a new project in C would be appropriate...? > Try writing a JSON api in pure C backed by a NoSQL db That's rather under-specified (what kind of JSON API?), but there are very few cases where you would actually want to write such an API in C, maybe unless you're actually working on the DB bindings themselves, and assuming the DB is in C/C++. Even then, it's arguable whether JSON is the ideal serialization. Choose the right tool for the job. [1] I'd argue that Makefiles and M4 are still very useful on their own and it'd behoove developers of all kinds to learn them anyway... maybe we'd have less (poorly done) reinvention with idiosyncratic, flavor-of-the-day build systems.

klodolph 11y ago

I've been using CMake off and on for years now, including recently. I feel no joy using it. The syntax is ridiculous, the semantics are worse, and the documentation is poor, even in 2016. It gets the job done, but it is a royal pain in the butt. Whenever feasible, I'll use something else. These days, that usually means writing a quick build script generator in Python. I've been around for a while, so I remember using a lot of different build tools, from monstrosities like autotools (which has good points), hand-written makefiles, to "modern" designs like Jam, SCons, NAnt. CMake is basically the least usable of all of these (except autotools), but at the same time it is the only one which solves the desired task. I wouldn't say that it's just a matter of money and popularity. C and C++ are both quite popular these days. The problem is that the tooling is so different between platforms. You want to build a shared library? Hah, the process is quite different on Windows, and there are non-trivial differences between OS X and Linux too. You need to change your header files on Windows depending on whether the library is static or dynamic, and you even need to worry about things like "who calls free()" because as soon as you make a DLL you can't be sure that the person calling your code has the same malloc that you do. With JS, Go, and Rust, the toolchain is identical on all platforms, there are no header files, et cetera. We've had decades to try and make C tooling nice and easy, and it simply hasn't happened, despite the language's overwhelming popularity. The most usable solution we've really come up with is writing C on your favorite Linux distro, where you can just apt-get whatever you want and pkg-config it into your build system. But once you want to build on OS X, you get to choose between the insanity of Homebrew or the insanity of building your own packages. On Windows, things are even harder, because suddenly all the shell scripts that propped up your build system stop working. Your experience on Arch just reflects the reality of cross-platform development: it's awesome if you can avoid it. I do most of my development on a Linux system as well and I can reasonably call it a "joy" right up to the point when I need to finish the Windows and OS X ports. I don't think that you can truly experience the horrors of CMake if you stick to Linux. Heck, on Linux, you can hand-write makefiles fairly reasonably, if you know what you're doing.

spriggan3 11y ago
On Windows I was rather successful with developing C apps with msys2 which comes with a Posix envirronment and pacman package manager. Most source that use posix compliant apis compile on windows and mingw provides a few handy adapters. It's obviously not going to run docker containers but it's really handy, I was successful compiling quite a lot of c projects from scratch, including some Gtk3 apps.
- klodolph 11y ago
  Unfortunately, that won't work for me. Compiling with MSC is a requirement, for various reasons.

spriggan3 11y ago

> So perhaps I've made it clearer as to why C is less popular now C is "not popular" (that's relative) because C is verbose, practical C is ugly and just dangerous if not in expert hands. I'm not a fan of Go but Go doesn't have C memory management problems. The complexity of C development is also in the tooling, Cmake, make, autotools , autogen and co ... imagine you're a beginer today , you need to write a server . It's like 4 lines in Go then you just type Go build. With C you'd have to install the proper library, then choose a build tool, then learn another language like make , then learn m4 macros ; then learn to do proper memory management , ... it takes way more than a day to get started, it takes months ... C lacks of a lot of modern features such as namespaces, simple string support, ... C isn't going away, Linux kernel is written in C so it will always be a dependency but explaining why C is the last choice when developing applications is pretty easy. Try writing a JSON api in pure C backed by a NoSQL db , then try the same with Go or Rust. You might be an C expert so ask someone that is a noob in software development to do the same, from scratch and watch the amount of time it takes to do so. Now give him Go to write the exact same thing ...

jallmann 11y ago
While the problem space where C would be appropriate has been shrinking, this rant is nonsense. > With C you'd have to install the proper library, then choose a build tool, then learn another language like make , then learn m4 macros ; then learn to do proper memory management What library? The libc that is on every OS? Build tools and Makefiles aren't exclusive to C; any non-trivial project is going to have tooling, no matter the language [1]. Also, if you don't understand memory management, then why do you think starting a new project in C would be appropriate...? > Try writing a JSON api in pure C backed by a NoSQL db That's rather under-specified (what kind of JSON API?), but there are very few cases where you would actually want to write such an API in C, maybe unless you're actually working on the DB bindings themselves, and assuming the DB is in C/C++. Even then, it's arguable whether JSON is the ideal serialization. Choose the right tool for the job. [1] I'd argue that Makefiles and M4 are still very useful on their own and it'd behoove developers of all kinds to learn them anyway... maybe we'd have less (poorly done) reinvention with idiosyncratic, flavor-of-the-day build systems.