4 ms·

One of the other things that autotools does that cmake does (admittedly badly) is provide a "configure" step that gives a much more controllable interface into

One of the other things that autotools does that cmake does (admittedly badly) is provide a "configure" step that gives a much more controllable interface into enabling or disabling features of a program. The problem with autoconf in particular is that it spends a lot of time trying to paper over the compatibility issues of ancient Unixes, whereas modern portability tends to rely more on a concept of a portable abstract system layer. The latter means that most of the work a configure step needs to do isn't "does your system have $UNIX_SYSTEM_CALL" but instead "what OS is this."

amiga386 2y ago
I see it both ways. On the one hand, sure Windows vs macOS vs "Linux/BSD" is so very different, you mainly need OS detection. On the other, I don't need a list of the exact featuresets of Fedora, Debian, FreeBSD, NetBSD, OpenBSD, DragonBSD, MorphOS, etc. so I can write narcissism-of-small-differences shit like: #if defined(SUNOS_V4) || defined(_MSC_VER) || defined(GNU) || defined(FREEBSD) # include <strings.h> #else # include <string.h> #endif I will _gladly_ run a feature test and write: #if HAVE_STRINGS_H # include <strings.h> #endif #if HAVE_STRING_H # include <string.h> #endif That is soooooooo much cleaner
- bandrami 2y ago
  This came up with musl, IIRC, and was problematic: the existence of a named header doesn't guarantee it contains what you think it does
- johnisgood 2y ago
  Speaking of, I am using https://zolk3ri.name/cgit/m4conf/about/ https://zolk3ri.name/cgit/m4conf/about/ so I do not have to use anything more bloated or complex.
danudey 2y ago
You can configure things with cmake! All you need to do is 1. Figure out what varibles you want to change 2. Add a -DVAR_NAME=value parameter to the command-line! ...which sucks to do. Meson is a much better way of doing things, but even that falls into "Here are the supported flags and settings, and then here are variable names for everything else"

amiga386 2y ago

I see it both ways. On the one hand, sure Windows vs macOS vs "Linux/BSD" is so very different, you mainly need OS detection. On the other, I don't need a list of the exact featuresets of Fedora, Debian, FreeBSD, NetBSD, OpenBSD, DragonBSD, MorphOS, etc. so I can write narcissism-of-small-differences shit like: #if defined(SUNOS_V4) || defined(_MSC_VER) || defined(GNU) || defined(FREEBSD) # include <strings.h> #else # include <string.h> #endif I will _gladly_ run a feature test and write: #if HAVE_STRINGS_H # include <strings.h> #endif #if HAVE_STRING_H # include <string.h> #endif That is soooooooo much cleaner

bandrami 2y ago
This came up with musl, IIRC, and was problematic: the existence of a named header doesn't guarantee it contains what you think it does
johnisgood 2y ago
Speaking of, I am using https://zolk3ri.name/cgit/m4conf/about/ https://zolk3ri.name/cgit/m4conf/about/ so I do not have to use anything more bloated or complex.

danudey 2y ago

You can configure things with cmake! All you need to do is 1. Figure out what varibles you want to change 2. Add a -DVAR_NAME=value parameter to the command-line! ...which sucks to do. Meson is a much better way of doing things, but even that falls into "Here are the supported flags and settings, and then here are variable names for everything else"