There are so many bugs like the "added dot to disable landlock" added as part of this action (which can also be typos [0]), not to mention that relying on some tools in autoconf to set feature flags will just disable them if those tools are not present [1].
[0] https://twitter.com/disconnect3d_pl/status/17744965092596453...
[1] https://twitter.com/disconnect3d_pl/status/17747470223623252...
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.
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.
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.
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.
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.
(that’s unfair, there’s probably tooling to build the shell scripts automatically I bet)
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.
I can't take this criticism seriously. 200kb of configure script = good, 1000 lines of JSON parser in bash = bad? What?
That wouldn't be consistent with the "unix philosophy".