[josephg]

I don’t understand how this is still the best way to test if features are available in C. Can’t the OS / environment provide a “features_available” JSON blob listing all the features on the host system? Is AVX2 available on the cpu? OpenSSL? (And if so, where?) and what about kernel features like io_uring?

Doing haphazard feature detection by test compiling random hand written C programs in a giant sometimes autogenerated configure script is an icon of everything wrong with Unix.

This hack shows that the haphazard mess of configure isn’t just ugly. It’s also a pathway for malicious people to sneak backdoors into our projects and our computers. It’s time to move on.

[thesuperbigfrog]

>> Can’t the OS / environment provide a “features_available” JSON blob listing all the features on the host system? Is AVX2 available on the cpu? OpenSSL? (And if so, where?) and what about kernel features like io_uring?

There are some utilities like pkg-config [1] and /proc/cpuinfo [2] that try to provide useful configuration information in distribution agnostic ways.

[1] https://en.wikipedia.org/wiki/Pkg-config

[2] https://www.baeldung.com/linux/proc-cpuinfo-flags

>> Doing haphazard feature detection by test compiling random hand written C programs in a giant sometimes autogenerated configure script is an icon of everything wrong with Unix.

True, but it works quite well which is why it is widely used. If you need to ensure that your C code will implement a desired feature, testing it with a small program before building makes a lot of sense. With different operating systems running various C compilers that all work slightly differently, it is a proven approach that achieves the needed outcome, however ugly it might be.

[rcxdude]

A similar thing could easily be done with other approaches: a typo of a feature name would have the same effect. The main issue is autoconf is such a mess of layered bad scripting languages it's impossible to really get a good idea of what is actually going on.

In general I think feature detection is probably not necessary for most cases (especially the cases that a huge number of autoconf scripts do: the number of linux-only projects which have feature detection for a feature which is certainly present is ridiculous). It's much more reasonable to just try to build with all features, and provide manual flags to disable unwanted or unavailable ones. These at least mean the user/maintainer can decide more explicitly if that feature should be present or not.

[jcranmer]

A few things here.

First, yes, there's several tools which provide (incomplete) feature selection functionality, you can see some sibling comments for examples.

Second, especially in complex projects, the presence of a feature doesn't necessarily mean it's sufficiently complete to be workable. You can run into issues like, say, "I need io_uring, but I need an io_uring op added in version X.Y and so it's not sufficient to say 'do I support io_uring.'" Or you can run into issues like "this feature exists, but it doesn't work in all cases, particularly the ones I want to use it for."

Third, there's no real alternative to feature detection. In practice, build systems need to cope with systems that pretend to be other systems via incompletely-implemented compatibility layers. Version detection ends up creating the User-Agent problem, where every web browser pretends to be somebody pretending to be somebody pretending to be Netscape 5.x and if you try to fix this, the web breaks. (Not to mention the difficulty of sniffing versions correctly; famously, MS skipped Windows 9 reportedly because too many build systems interpreted that to mean Windows 95 or Windows 98 with catastrophic results).

The end result of all of this is that the most robust and reliable way to do feature detection is to try to use the feature and see if it works.

[josephg]

> In practice, build systems need to cope with systems that pretend to be other systems via incompletely-implemented compatibility layers.

That sounds fine though. If the system claims to provide feature X, you probably want the program in question to compile assuming feature X is available. If the compatibility layer doesn’t work as advertised, a compiler error is a great choice. Let the user choose to turn off that flag in their system configuration when building the project.

I’m not proposing user agent sniffing. I’m proposing something much more fine grained than that. Make something that looks more like the output of configure that build systems can use as input.

[xorcist]

Satire is so hard on the Internet and maybe I'm just thick headed. Just to clarify things, is that a suggestion to shove a JSON parser into either bash or autoconf?

[paulmd]

JSON is too far, says the engineering culture still relying on a pile of shell scripts like it’s 1970.

(that’s unfair, there’s probably tooling to build the shell scripts automatically I bet)

[xorcist]

You have it backwards. The engineering culture that said autoconf increases attack surface, the culture that said that the design of PAM is too complex, that did not accept the patch to link libsystemd to sshd, is the one that constantly tries to avoid unnecessary dependencies.

The engineering culture that non-ironically suggests linking a JSON parser is the culture that disregards the challenges that maintaining dependencies brings.

Yesterday it may have been soups of automatically generated shell scripts, but today it is soups of automatically generated YAML and JSON.

[josephg]

... The engineering culture which gave us 200kb fragile, semi-autogenerated configure scripts checked in to our repositories. Configure scripts which - as we've just seen - are a great place to hide malicious code.

I can't take this criticism seriously. 200kb of configure script = good, 1000 lines of JSON parser in bash = bad? What?

[bigbillheck]

> Can’t the OS / environment provide a “features_available”

That wouldn't be consistent with the "unix philosophy".

[turol]

https://xkcd.com/927/

[okr]

"How to demotivate people and prevent innovation!"

[josephg]

I think that would land harder if configure / automake / autoconf were actually a standard. And not, you know, a bunch of cobbled together shell scripts that generate other shell scripts.

[actionfromafar]

It quacks pretty much like a standard though.