[jschwartzi]

Autotools is the de facto build system for most of the GNU system programs. The bit about dependency management mostly fits but I would argue that letting us figure out how to build and install the dependencies is fairly UNIXy. It’s also unclear to me that centralized package managers are necessarily better for security, though they’re easier to use. Also a lot of more modern tools I’ve tried to build in recent months do not give a crap about cross compilation as a use case. At least with autotools its supported by default unless the library authors did something egregious like hard coding the sysroot or toolchain paths.

[throwaway894345]

EDIT: Just re-read the below and realized it might sound terse and argumentative; apologies, I was typing quickly and didn't mean to be combative. :)

> I would argue that letting us figure out how to build and install the dependencies is fairly UNIXy

Crumby build systems force you to figure out how to build and install dependencies (or die trying). Modern build systems allow you to figure out how to build and install dependencies. If the former is "more UNIXy" than the latter, then I strongly contend that "UNIXy" is not a desirable property.

> It’s also unclear to me that centralized package managers are necessarily better for security, though they’re easier to use.

"Centralized" is irrelevant. Go's package manager is decentralized, for example. Moreover, many folks in the C world rely heavily on centralized repositories. Further, I would be shocked if manually managing your dependencies was somehow less error prone (and thus more secure) than having an expert-developed program automatically pull and verify your dependencies.

> Also a lot of more modern tools I’ve tried to build in recent months do not give a crap about cross compilation as a use case.

I mean, C doesn't care about anything, much less cross compilation. It puts the onus on the developer to figure out how to cross compile. Some build system generators (e.g., CMake, Autotools) purport to solve cross compilation, but I've always had problems. Maybe I just don't possess the mental faculties or years of experience required to master these tools, but I think that supports my point. By comparison, cross compilation in Go is trivial (set `CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build` works virtually every time from any platform). I haven't done much Rust cross-compilation, but I would be surprised if it were harder than C/C++.

[mid-kid]

I can't speak for cmake but in autotools it's always just been "./configure --host=aarch64-linux-gnueabi" or whatever other target triplet is of relevance. It's similar in Meson.

The annoying factor is gathering the cross compiler and target dependencies, which is fortunately becoming easier with tools such as llvm/clang, and distros such as debian have always made huge efforts to facilitate it.

[saghm]

> Also a lot of more modern tools I’ve tried to build in recent months do not give a crap about cross compilation as a use case

On the other hand, more modern languages like Rust and Go tend to have a single standard library and compiler that can be used across basically any common operating system, whereas trying to use gcc/libstdc++ or clang/libc++ on Windows can be an ordeal, and using MSVC on Unix is essentially not an option at all. Cross compilation for other architectures might be a bit more work, but the majority of developers don't have to worry about that very much, whereas support across Linux, MacOS, and Windows is a lot more common.